Hi Thorsten, Norbet, all, On Sun, 22 May 2011 01:29:37 +0200 Thorsten Behrens <t...@documentfoundation.org> wrote:
> > Another route is the 'sub-system maintainer' route. where patch and > > commit are channeled to sub-system maintainer that regularly but in > > a controlled fashion push batch of commits to the 'official' master. > > For instance 'calc'-centric patch could transit via a tree managed > > by kohei, he would make sure that he tree is stable (via builtbot > > among other tings) and weekly - for instance - would merge his tree > > into the 'official' master. > > > I think I like that plan much better. The original proposal is > really heavy-weight, and relies on people being able to fix the > unreviewed branch in time, no matter how broken it is. Also, it > unnecessarily requires syncing of all work, on certain days. Kernel style subsystem maintainers would be great IMHO, but I had the feeling that there is a general opposition against a 'too branchy' development model. After all a lot of the criticism against CWS in general (for example the longer time to integration in master) applies to feature branches (or subsystem branches) too. The Linux Kernel shows that this model can work. However, I dont think it will be more lightweight: - You would need to make sure that patches that touch multiple subsystems do not get lost. - You would have to seamlessly coordinate for maintainers being on vacation or on conferences or whatever. - You would need to make the tinderboxes work a lot more on the feature branches in an intelligent way. For example, not having the Windows tinderbox to build each branch at least twice a week would result in very painful regression searches. I know from experience, that scheduling tinderboxes to cover this sufficiently once you have a few more branches is not trivial. So, yeah: I would love to see such a setup, but I have the feeling that it is a lot more work than assumed right now, which was the reason for my more ad-hoc proposal. And even with subsystem maintainers, I think galvanizing reviews in something like informal Review-Mondays would be a good thing. On Sat, 21 May 2011 16:45:08 -0500 Norbert Thiebaud <nthieb...@gmail.com> wrote: > And the reciprocal problem of Sunday.... a lot of email submitted > patch are posted > by volunteers, that may not have the liberty to hang around IRC on > weekday... Not to mention timezone issues. I dont think it is critical that patches are getting reviewed the next day -- but it is critical that they do not rot for more than two weeks. And about the voluteers on weekday: true, but this is just an addtion to the current situation, where a patch submitter has no idea when somebody will review his patch, even if he wanted to be available for discussion on IRC -- he would have to arrange for that explicitly. Also I think patch submitters might be unsure about when to politely ask about the status of a stalled patch. "Review-Mondays" would be a good opportunity. On Sun, 22 May 2011 01:29:37 +0200 Thorsten Behrens <t...@documentfoundation.org> wrote: > Both are non-issues in my mind. The former happens very, very > seldomly, the latter is not solved by Björn's proposal - since it's > about release branches. No, my original proposal was to have such a branch for the release branches too. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
