[Libreoffice] breathing master

[Bjoern Michaelsen]

Hi all,

here is a proposal to improve our handling of patching and commits on
master.
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
  http://en.wikipedia.org/wiki/Broken_windows_theory

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
  branch.
- 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
  resubmitted.

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
  them.
- It is easier to identify and find a domain expert when doing a "group
  review"
- Reduce the noise on the dev mailing list.
- Newcomers can be sure that a Sunday evening checkout of master is
  stable.
- 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
  list.
- 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.

Opinions?


Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen