[Libreoffice] breathing master
ikojba at gmail.com
Sat May 21 09:48:49 PDT 2011
Seems pretty OK to me :)
2011/5/21 Bjoern Michaelsen <bjoern.michaelsen at canonical.com>:
> Hi all,
> here is a proposal to improve our handling of patching and commits on
> LibreOffice is aiming for a welcoming and inviting culture to aloow
> newcomer get invaolved fast. This is why we have a very lax requirement
> on commits to master and are inviting people to post patches to the
> dev ML too.
> However, this has shown to be problematic in many ways:
> - Patches and reviews are making the dev-mailing list very noisy.
> - Newcomers are distracted by this.
> - Oldtimers elude the idea on the mailing list being integrative,
> by filtering out patches (thus having effectively a separate patch
> mailing list).
> - Patches are hard to keep track of in the mailing list, esp. the
> "needs-how-many-more-reviews" question.
> - Patches wait way too long to be reviewed and pushed because of this.
> - Stability of master is way too low: Newcomers are driven away, if they
> need to search and find for the commit which builds master and
> survives basic testing.
> - Response time to "you broke the master"-emails by tinderboxes are way
> too low -- the default assumption seems to be: somebody else broke the
> master. This is having further implications as per
> Here is a proposal on how to solve this:
> - Create an branch named "unreviewed" branching off from master on
> every Tuesday 00:00 UTC.
> - Any submitted patch is pushed to that branch as is without review from
> Tuesday until Saturday, the only condition is a proper license.
> Patches from Sunday and Monday will wait to get pushed on Tuesday.
> - The master branch will be open for commiters from Monday to Saturday
> UTC for all commits, Sunday UTC is reserved for stabilzation: Only
> commits fixing build breakers and test breakers are allowed. On
> Sunday evening, every tinderbox should be shiny green. If you
> absolutely need to commit something else on Sunday, use a feature
> - Tinderboxes should also do one build of the "unreviewed" branch on
> Sunday, to identify obvious build or test breakers.
> - On Monday, the commits on the "unreviewed" branch are being
> collectively reviewed and discussed on IRC. Accepted patches are
> cherrypicked to master, results are posted to the mailing list, the
> "unreviewed" branch is deleted. Rejected patches can be fixed an
> This would:
> - Prevent patches to get lost in space on the ML.
> - Prevent patches to hang in a "needs one more review" cycle.
> - Limit the waiting time for a patch review to maximum one week.
> - Patch submitters can be around on IRC at review time and clarify
> questions and receive feedback directly. Otherwise little changes for
> - It is easier to identify and find a domain expert when doing a "group
> - Reduce the noise on the dev mailing list.
> - Newcomers can be sure that a Sunday evening checkout of master is
> - The "learning experience" by patch reviews will actually be improved:
> There will be a good summary of all the reviews done on Monday,
> instead of lots of tiny bits sprinkled here and there over the mailing
> - The only drawback is the limitation to direct commits on Sunday, but
> there is little activity anyway on Sunday. (And if it is not a
> buildbreaker/test fix, how can it be so important that it cant wait
> for the next day?)
> This workflow gives our review process a bit more stucture without the
> need for new tooling (with new accounts etc.) like reviewboard, but
> instead really uses the power of our existing tooling.
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
More information about the LibreOffice