Seems pretty OK to me :)
2011/5/21 Bjoern Michaelsen <bjoern.michael...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
