Hi Sebastien: So I like the idea of:
1. Us putting up all inbound code for review. 2. Gating that code on a testing pass 3. Having someone else look at it before committing. I don't think that should mean that all code that works gets an immediate pass. I also don't think that we should have n RMs for branches. It doesn't scale, and it moves us from consensus to authoritarian. I am all for reverting things that break, but think that should be a community wide responsibility, not one or two policemen. I also think this is a huge shift in process. Right now we have 145 open patches on ReviewBoard. We average scores of commits per day; so understand that this is a huge, gigantic shift in how we work. This requires a high level of commitment from everyone, and frankly it's likely to bury TravisCI. I also worry about the effect of this on our ability to timely ship 4.5. We have 14 Critical and blocker bugs for 4.5, and part of me worries that this is a distraction for 4.5 release efforts. Please don't take this as discounting your proposal or your concerns. I don't think that many folks disagrees in principle with the first 3 points above. But timing, and implementation details may be an issue. --David On Sat, Oct 18, 2014 at 5:00 AM, sebgoa <run...@gmail.com> wrote: > After [1] I would like to officially bring up the following proposal. > > [Proposal] > ---- > All commits come through github PR, *even* for committers. We declare a > moratorium period (agreed suspension of activity) during which direct commit > to master is forbidden. > Only the master RM is allowed to merge PR in master (we define a master RM). > If direct commit to master is done, master RM reverts without warning. Same > for 4.5 and 4.4. branches. > ---- > > This is drastic and I am sure some folks will not like it, but here is my > justification for such a measure: > > [Reasons]: > ---- > Our commit and release processes have so far been based on the idea that > development happens on master and that a release branch is cut from master > (unstable development branch). Then a different set of community members > harden the release branch, QA and bring it to GA level. During that time > development keeps on going in master. > > This is an OK process if we have the luxury of having a QA team and can cope > with split personality of being developers and release managers. > > My point of view is that as a community we cannot afford such a split brain > organization and our experience overt the last year proves my point (delayed > release date, broken builds, features merged without warning…) > > We can avoid this by cutting a release branch from a stable one (from the > start), then as you (Daan) have mentioned several times, fix bugs in the > release branch and merge them back in the stable source of the release (be it > master). > > Feature development need to be done outside master, period. Not only for > non-committers but also for committers. And merge request need to be called. > This will help review and avoid surprises. > > New git workflow were proposed and shutdown, mostly calling for better CI to > solve quality issues. CI will not solve our quality issues alone. We need to > better police ourselves. > > To avoid long discussions, I propose this simple but drastic measure. We move > all our commits to github PR until 4.5 is out, this stands for committers and > non-committers, direct commits (especially to master) would be reverted > immediately. > ---- > > Our development and release process is broken, we cannot continue like this, > let's fix it. > > [1] http://markmail.org/thread/xeliefp3oleq3g54 > > -sebastien
