On Oct 21, 2014, at 9:36 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> Ok, no one says it so let me be the bad guy. > > <rant> > Nothing will work unless the citrix department in california agrees. They > have their in-house legacy proces to change and will not unless they can > sell it easily upstream. So whether we make a grand uninfied proposal or > take small steps doesn't matter, it must fit their internal political > situation. > This is very unhealthy. I am not saying that the objections coming from > that group are unreasonable every time. Sometimes they were more then other > times. I am even sure that they are working on improving as well but this > is invisible to the rest of us. A mail every once in a while does not make > this visible. The proces of improving the way we work is impaired by it. > They to need to make small steps so we can see what is happening and where > we are going. Even a grand proposal by Citrix California won't be accepted, > because the change will be to big! > </rant> > > <frustrated conclusion> > I made some small steps in improving during the 4.4.1 release process. > These were largely ignored or reverted in the current branch. unless the > current state of 4.5 happens to be very good we are in for a repeat of > recent history. > </frustrated conclusion> > > You know where to find me, > Daan I will mostly +1 this -sebastien > > On Tue, Oct 21, 2014 at 6:32 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Code reviews are great. >> >> However, we will need to change our behavior quite a bit if code is to make >> it in within a reasonable amount of time as code reviews today often don't >> get done in a timely fashion. >> >> In a volunteer community, it's hard to "assign" work (including code >> reviews) to people (let alone expect it done on your schedule). >> >> This is, of course, different at most of our day jobs where managers are in >> a position to make sure the community is responsive. >> >> On Monday, October 20, 2014, Rajani Karuturi <raj...@apache.org> wrote: >> >>> I like the way Stephen split it. >>> Here is my vote. >>> +1 on using github pull requests. >>> +1 on compulsory code reviews and PRs even for committers and CI build >> pass >>> before merging. >>> +1 on merges from 4.5 to master and no individual commits(or >> cherry-picks) >>> to the branches >>> +0 on RM for master and commits gated by him. I agree with Stephen that >>> code reviewer should be doing the push. But, I am ok with RM doing >>> it(assuming we have a volunteer ;) ). >>> >>> +1 on any changes independently. >>> >>> >>> ~Rajani >>> >>> On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner < >> stephen.tur...@citrix.com >>> <javascript:;>> >>> wrote: >>> >>>> As I just said in the other thread -- but to repeat it here in the >>>> PROPOSAL thread -- >>>> >>>> I am +1 on using github pull requests. >>>> >>>> I am +1 on all code changes being reviewed by a committer other than >> the >>>> author, as well as undergoing some automated CI testing, before the >> pull >>>> request is merged. >>>> >>>> I am +0 on only the master RM merging the pull request. I don't want >> the >>>> author to push the code, but I think the code reviewer could do this; >> in >>>> practice the RM will not be able to review everything again so is >> likely >>> to >>>> rubber-stamp the results of the code review / automated testing. But I >>>> could live with the master RM doing it. >>>> >>>> I am +1 on moving ahead with any of these parts individually, rather >> than >>>> waiting for everything to be in place before doing anything. >>>> >>>> -- >>>> Stephen Turner >>>> >>>> >>>> -----Original Message----- >>>> From: sebgoa [mailto:run...@gmail.com <javascript:;>] >>>> Sent: 18 October 2014 10:00 >>>> To: dev@cloudstack.apache.org <javascript:;> >>>> Subject: [PROPOSAL] Move to github PR only during moratorium on commit >>>> >>>> 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 >>>> >>> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >> > > > > -- > Daan
