[Libreoffice] breathing master

[Joop Kiefte]

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
> 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
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>