Sorry guys, I haven't followed up the thread. But I think we probably jump to conclusion too quickly. I found the discussion mostly took place later last week. I'm afraid not enough people aware of what's happening.
I am trying to catch up, by reading the thread and checking what's gitflow etc, but could someone already familiar with the topic give an overview of the issue? For example, we can start by asking these questions: 1. What's the issue with current development process? 2. What's the purposed new approach to the process? 3. What's the pro/con of the new process? And what's the pro/con of the old one? That would make the question much more clear. Thanks. --Sheng On Mon, Jul 28, 2014 at 1:54 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > Rohit, > > Let's change the howto-use-git page after the vote. > > On Mon, Jul 28, 2014 at 6:47 PM, Stephen Turner > <stephen.tur...@citrix.com> wrote: > > I am +1 on the principle. > > > > -- > > Stephen Turner > > > > > > -----Original Message----- > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > Sent: 28 July 2014 16:08 > > To: dev > > Subject: Re: [DISCUSS] git commit proces > > > > 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 > > > > -- > Daan >
