[Libreoffice] breathing master

[Bjoern Michaelsen]

Hi Thorsten, Norbet, all,

On Sun, 22 May 2011 01:29:37 +0200
Thorsten Behrens
<thb at 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 <nthiebaud at 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
<thb at 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