Let me explain a little more about this lat mail of mine. I was assuming a lot of context that most people may not have. We want to start working differently with respect to our release procedure and branching habits. The proposals that are out there and about to be voted for are going to require a lot of work of a few people and a lot of discipline from all of us.
My idea was to first vote for some of the habits that are part of the gitflow discipline, but I am not strong opinionated about that. I do want to prevent that we go for a grand proposal to completely change our way of moving forward (not just the way we move forward) while there are potentially people opposing to this way of working. So please give a +1/0/-1 to the general idea now, so we fell comfortable spending the time in devising a new release schedule/mechanism. some of the highlights are: it will start with 4.5 (4.4.x will be done with the old manual cherry-pick process) it will require everybody to create a branch for every fix or feature they will contribute. it will require devs to work mainly on a new branch call 'develop' it will be every bodies responsibility to ensure that 'master' is at all times releasable thanks, Daan On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > I am not for a grand proposal but ok, I can live with it. > > It would be easiest to just vote for using the gitflow model. > Leo is preparing a page on how to do it. I don't know what the status > is on it. The vote for my part would be on the contents of that page. > > On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: >> Yeah, I was under the impression this decision would require a vote and >> formal announcement, if it passes. >> >> On Monday, July 28, 2014, Hugo Trippaers <h...@trippaers.nl> wrote: >> >>> Agreed, this kind of important decisions should be made by a vote. >>> >>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a >>> condensed summary of the thread? >>> >>> Cheers, >>> >>> Hugo >>> >>> >>> On 28 jul. 2014, at 14:07, Ian Duffy <i...@ianduffy.ie <javascript:;>> >>> wrote: >>> >>> > +1 to what Erik said. >>> > >>> > >>> > On 28 July 2014 13:04, Erik Weber <terbol...@gmail.com <javascript:;>> >>> wrote: >>> > >>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <daan.hoogl...@gmail.com >>> <javascript:;>> >>> >> wrote: >>> >> >>> >>> H, >>> >>> >>> >>> I see a lot of commits happening directly on the master branch. Yet >>> >>> there were no counter arguments against the proposed gitflow and the >>> >>> discussion around it. This leaves me with the idea that the thread is >>> >>> largely ignored by the community. It is my understanding that we >>> >>> agreed never to commit anything to master anymore that hasn't been >>> >>> first committed to a branch and is merged back to master (instead of >>> >>> cherry-picked). What mistake in thinking am I making here? >>> >>> >>> >>> >>> >> >>> >> Not familiar with bylaws and the such, but wouldn't a change like this >>> >> require some sort of voting and potentially a more formal information? >>> >> >>> >> Requiring everyone to read through a 50+ replies mail thread and >>> comprehend >>> >> it could be a bit much. >>> >> >>> >> I would suggest an updated document that explain the expected workflow. >>> >> >>> >> -- >>> >> Erik >>> >> >>> >>> >> >> -- >> *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 -- Daan
