Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Thorsten, Norbet, all,

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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.