On Oct 22, 2014, at 1:21 AM, David Nalley <da...@gnsa.us> wrote: > 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
I respectfully disagree with you. I hear your concerns but I feel that we are at a stage where we need drastic measures. I understand this may sound like an authoritarian proposal but this is how I see it, I don't like the way we develop cloudstack and I am not even a software engineer. I am off for 2 weeks, and won't be able to check on this or defend this proposal. -sebastien > > 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
