[Libreoffice] breathing master
bjoern.michaelsen at canonical.com
Sat May 21 05:02:55 PDT 2011
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
- Patches are hard to keep track of in the mailing list, esp. the
- 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
- 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.
More information about the LibreOffice