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
