To start this all off, what about making a new branch call 'develop' off of 'master'? People can continue to commit to 'develop' as needed (as they were doing previously to 'master'), but only cherry pick well-tested features into 'master'.
I know 'master' might not be currently in a shippable state (or maybe it is), but we can allow it to slowly make such a transition during the 4.5 release and then keep it in a shippable going forward. On Wed, Jul 23, 2014 at 9:51 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > On Jul 23, 2014, at 11:38 AM, daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > Sebastien, > > > > It seems we can do what you are calling for is creating a branch > > called 'release'. We can merge back into that branch from 4.4, master, > > 4.3. I would like to see people that want a feature or bug fix in a > > branch make a fork of that branch and when that fork is working do a > > cherry-pick. The -forward concept is now used for that but it is > > broken because more then for one piece of work there are commits on > > it. This caused me conflicts during the release. Especially painfull > > as not all was intended to get into the release. We can create this > > 'release' branch now on the basis of 4.4 and start pulling in changes. > > Yes, that's what I am thinking about too, so +1 > > Our master would become the -develop- in gitflow terms > The release branch you mention would become the -master- in gitflow terms > > If we start now, indeed we can create 'release' from 4.4 release tag > (voted and shipped). > > That means that to create 4.5 we will need to merge features back into > 'release'. it might be messy because some of those features are already in > our current master. > > But all of this will keep 'release' clean (we can keep track of bugs and > features that are in it in CHANGES file etc..) > > > > There is a question of control. Do we allow all committers to manage > > the release? I am for that but can imagine not everybody is. > > > > At first I would say that only the RM can commit to 'release'. As we get > the CI in place we could relax this and allow commits that pass the CI to > get into 'release', but right now I would vote for a tighter control of > 'release'. > > > rule number 1 will be: you are going to do something to the code, you > > start by creating a branch. > > > > right? > > > > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <run...@gmail.com> > wrote: > >> > >> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sam.sch...@appcore.com> > wrote: > >> > >>> Hey everyone, > >>> > >>> I've been a developer for a handful of years and have had my share of > >>> experience with different version control systems. I've used (for > better > >>> or worse) Git, Perforce, Rational ClearCast, and SVN. > >>> > >>> Each of these solutions offers their own unique set of features, > strengths > >>> and weaknesses. As there are so many systems that are good at specific > >>> things, it seems best to use the features that the chosen system is > best at. > >>> > >>> Git is great at branching, merging and using that structure to > maintain and > >>> control how changes get into the primary branches. Git tools even make > >>> this easy by integrating directly into the "Gitflow" to make branching > and > >>> merging that much easier. It would seem counter-intuitive to NOT make > use > >>> of these built-in capabilities. > >>> > >>> In addition to that, I know that the current method of change > management is > >>> incredibly frustrating to work with, and works directly against the > way a > >>> typical Git user would expect it to be structured. I should NEVER have > >>> problem compiling and running something on master. I should not have > >>> problems building anything on a release branch. A feature/bugfix > branch is > >>> where things can be, and often are, broken or unstable. There have > been > >>> many times working in Cloudstack where I've had to search for a stable > >>> revision on master, and that's just plain wrong. > >>> > >>> I do realize that having this many developers working on so many > features > >>> and bugfixes will result in a large number of branches. I don't > believe > >>> this is a good argument against using a branching method, though - I > >>> believe that the current system is even more confusing and difficult > to use. > >>> > >>> I could pontificate on change management quite a bit more, but my > opinion > >>> in summary would basically be: use Git the way it was meant to be > used, > >>> and things will be better. Just my two cents. > >>> > >>> Sam > >>> > >>> > >> > >> Sam, I think we are in agreement (at least with folks who responded to > this thread). > >> Or maybe I am not reading your mail right and you don't agree with Leo ? > >> > >> My own take and reason for calling for a change we are currently doing > things is mostly due to the way we release. > >> > >> I would like to see a stable master (and I think we are in agreement > with that). > >> That means that development should not happen on master and that every > commit that lands on master should be shippable. > >> > >> I personally have no issues with cherry-picking. So I would be fine > cherry picking from a hot-fix branch into master, to fix a bug. > >> The end result is that the next commit on master would still mean > master is shippable/releasable. > >> > >> If we agree with this basic concept. The question becomes how do we get > there, considering that master is now full of dev work and potential bug. > >> The only releasable product we have are on the 4.3, 4.4 and previous > release branches. > >> > >> Ideally, I would like to see master becomes 4.4. And work our way back, > merging the new features that are already in master into the new master > (based on 4.4). > >> This could be quite complicated but we need to do it (or something like > it). > >> > >> To move forward, we should make a proposal to the list and call for a > vote. > >> > >> Any takers to start a wiki page proposing a new git process and how we > could move to it (transition path) ? > >> > >> > >> -Sebastien > >> > >> > >>> > >>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons < > lsim...@schubergphilis.com> > >>> wrote: > >>> > >>>> Hey folks, > >>>> > >>>> With 4.4.0 tagged, is now an opportune time to go and implement this? > >>>> > >>>> I would enthousiastically +1 and get crackin', but I’m not a > committer so > >>>> its not that practical for me to volunteer! > >>>> > >>>> I wanted to point out atlassian’s description of gitflow > >>>> > >>>> https://www.atlassian.com/git/workflows#!workflow-gitflow > >>>> > >>>> which might be easier to read. > >>>> > >>>> Similarly, the git-flow scripts that help out with implementing this > stuff > >>>> > >>>> https://github.com/nvie/gitflow > >>>> > >>>> they also describe the relationship between gitflow and dealing with > >>>> multiple remotes > >>>> > >>>> https://www.atlassian.com/git/workflows#!pull-request > >>>> > >>>> Finally note atlassian’s free sourcetree GUI has built-in support for > >>>> git-flow > >>>> > >>>> http://www.sourcetreeapp.com/ > >>>> > >>>> Because cloudstack currently is full of rebasing and squashing and > >>>> cherry-picking, you get very little benefit from a tree visualization > tool > >>>> (like this or gitk or ...) right now, but it would be *great* to have > going > >>>> forward. > >>>> > >>>> > >>>> cheers, > >>>> > >>>> > >>>> Leo > >>>> > >>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <run...@gmail.com> > wrote: > >>>> > >>>>> I would like to re-start this discussion. > >>>>> > >>>>> Rajani made some good points and someone mentioned Gitflow: > >>>>> > >>>>> http://nvie.com/posts/a-successful-git-branching-model/ > >>>>> > >>>>> Thinking about our release procedure, we clearly need more tests and > a > >>>> CI. However it looks like this is going to take some time. > >>>>> > >>>>> In the meantime I think there is nothing preventing us from agreeing > to > >>>> 'git practices', we don't need tests or new infra, we just need to > agree on > >>>> the git workflow. > >>>>> > >>>>> Right now Master is really a development branch, we should make it a > >>>> stable branch for production with very few commits. > >>>>> This does not mean that we would release less, in contrary this would > >>>> ensure that a commit to master means it's a production release. > >>>>> > >>>>> In addition gitflow [1] does not do cherry-picks (gets back to > Rajani's > >>>> point) everything is based on merges. > >>>>> > >>>>> I am of the opinion that git flow provides a nice process. It > basically > >>>> freezes master. Development happens in a 'develop' branch, releases > >>>> branches are branched off of that and merged into master and back into > >>>> develop….etc > >>>>> > >>>>> Please read [1] it's a good read. > >>>>> > >>>>> And let's discuss, > >>>>> > >>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/ > >>>>> > >>>>> -Sebastien > >>>>> > >>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi < > rajani.karut...@citrix.com> > >>>> wrote: > >>>>> > >>>>>> There is also the problem of cherry-picking. > >>>>>> As a contributor, I always endup creating multiple patches for each > >>>> branch as they don’t cleanly apply on the upward branches. which means > >>>> distinct commits for each branch and I don’t easily know which all > branches > >>>> my commit exists unless I do grep. > >>>>>> if we follow merging strategy properly, apart from the first merge > of > >>>> the branch, everything else on top of it should be a painless merge. > >>>>>> > >>>>>> > >>>>>> > >>>>>> ~Rajani > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <shadow...@gmail.com> wrote: > >>>>>> > >>>>>>> I think many of the bullet points are what we are currently doing > >>>>>>> (guidelines for commit comments, feature branches need to stay in > sync > >>>> with > >>>>>>> master, no back-merging). I also think that much of what we do now > is > >>>> done > >>>>>>> the way it is simply because there *are* vast changes between > versions. > >>>>>>> Classes are getting shuffled around and changed all the time. If > its > >>>>>>> feasible to merge branch fixes to master, that's fine, but some > quick > >>>> tests > >>>>>>> seem to indicate that this will be messy getting started. > >>>>>>> > >>>>>>> That leaves us with how we do releases. I'm fine with having single > >>>>>>> branches for major releases(4.3) and tagging the commits where each > >>>>>>> incremental release (4.3.x) is done. I'm trying to remember why we > went > >>>>>>> with the -forward, I'm sure it's in the mailing list somewhere, but > >>>> one of > >>>>>>> the nice things it provides is the ability for the release manager > to > >>>>>>> control what changes are made during code freeze while giving > people a > >>>>>>> place to stage fixes (though admittedly this is not always > followed). > >>>>>>> Without -forward, would the flow be for each dev to have their own > >>>> repo and > >>>>>>> issue pull requests for bugfixes? > >>>>>>> > >>>>>>> > >>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi < > >>>> rajani.karut...@citrix.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Any other suggestions/objections/comments?? > >>>>>>>> Can we discuss this in detail and agree to a process?? > >>>>>>>> > >>>>>>>> > >>>>>>>> ~Rajani > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi < > >>>> rajani.karut...@citrix.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Yes as mike said, if its a one-off case we can do a empty > >>>> merge(merge -s > >>>>>>>> ours) for it and git will assume its merged but will not bring in > any > >>>>>>>> changes. > >>>>>>>>> > >>>>>>>>> If the branches diverged a lot, for example after a major > rewrite, we > >>>>>>>> could stop merging to that branch and above and make the fix > manually. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ~Rajani > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski < > >>>>>>>> mike.tutkow...@solidfire.com> wrote: > >>>>>>>>> > >>>>>>>>>> Yep, that's what I was referring to in that a particular fix > for an > >>>> old > >>>>>>>>>> release may not apply to newer versions. That does happen. > >>>>>>>>>> > >>>>>>>>>> We used to mark those as "don't need to merge to branch x" in > SVN > >>>> and > >>>>>>>> then > >>>>>>>>>> you handed it however made sense on the applicable branch(es). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner < > >>>>>>>> stephen.tur...@citrix.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> What happens if a fix isn't relevant for newer versions, or > has to > >>>> be > >>>>>>>>>>> rewritten for newer versions because the code has changed? > Don't > >>>> the > >>>>>>>>>>> branches diverge and you end up cherry-picking after that? > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Stephen Turner > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > >>>>>>>>>>> Sent: 30 May 2014 18:48 > >>>>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow > >>>>>>>>>>> > >>>>>>>>>>> I think this flow is something we should seriously consider. > >>>>>>>>>>> > >>>>>>>>>>> I find cherry picking from branch to branch to be error prone > in > >>>> that > >>>>>>>> it's > >>>>>>>>>>> easy for someone to forget to cherry pick to all applicable > >>>> branches > >>>>>>>> and > >>>>>>>>>>> you don't have any easy way to see the cherry picks are > related. > >>>>>>>>>>> > >>>>>>>>>>> When I worked at HP, we had automated tools check to see if you > >>>>>>>> checked a > >>>>>>>>>>> fix into a prior release, but not later releases. In such a > >>>> situation, > >>>>>>>> you > >>>>>>>>>>> either 1) forgot to perform the check-in or 2) the check-in > was no > >>>>>>>> longer > >>>>>>>>>>> applicable in the later release(s), so you needed to mark it as > >>>>>>>>>>> un-necessary (SVN supported this ability...not sure about Git). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < > >>>>>>>>>>> rajani.karut...@citrix.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi all, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Our current git workflow is confusing with the *forward > branches > >>>> and > >>>>>>>>>>>> cherry-picking. Its hard to track on what all releases the > commit > >>>> has > >>>>>>>>>>>> gone into unless I do some git log greping. Also, as a > >>>> contributor, I > >>>>>>>>>>>> endup creating patches for each branch as it doesn’t cleanly > >>>> apply on > >>>>>>>>>>>> different branches. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I think we should have some guidelines. Here is what I > propose. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> 1. There should be branch for every major release(ex: 4.3.x, > >>>> 4.4.x, > >>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged > accordingly > >>>> on > >>>>>>>>>>>> the respective branches. > >>>>>>>>>>>> 2. The branch naming convention is to be followed. Many > branches > >>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing > >>>>>>>>>>>> 3. Cherry-picking should be avoided. In git, when we > cherry-pick, > >>>>>>>>>>>> we have two physically distinct commits for the same change or > >>>> fix and > >>>>>>>>>>>> is difficult to track unless you do cherry-pick -x > >>>>>>>>>>>> 4. There should always be a continous flow from release > branches > >>>> to > >>>>>>>>>>>> master. This doesn’t mean cherry-picking. They should be > >>>> merged(either > >>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily trackable > >>>> with > >>>>>>>>>>>> git branch --contains > >>>>>>>>>>>> * Every bug fix should always flow from minimal release > uptill > >>>>>>>>>>>> master. A bug isnt fixed until the fix reaches master. > >>>>>>>>>>>> * For ex. A bug 4.2.1 should be committed to > >>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master > >>>>>>>>>>>> * If someone forgets to do the merge, the next time a new > commit > >>>>>>>>>>> is > >>>>>>>>>>>> done this will also get merged. > >>>>>>>>>>>> 5. There should always be a continuous flow from master to > >>>> feature > >>>>>>>>>>>> branches. Meaning all feature branch owners should proactively > >>>> take > >>>>>>>>>>>> any new commits from master by doing a merge from master > >>>>>>>>>>>> 6. The commits from feature branch will make to master on > code > >>>>>>>>>>>> complete through a merge. > >>>>>>>>>>>> 7. There should never be a merge from master to release > branches > >>>>>>>>>>>> 8. Every commit in LTS branch(targetted to any minor release) > >>>>>>>>>>>> should have atleast bug id and correct author information > >>>>>>>>>>>> * Cassandra's template: patch by <author>; reviewed by > >>>>>>>> <committer> > >>>>>>>>>>>> for CASSANDRA-<ticket> > >>>>>>>>>>>> 9. Once the release branch is created(after code freeze), > any bug > >>>>>>>>>>>> in jira can be marked with fix version current release(4.4) > only > >>>> on > >>>>>>>>>>>> RM's approval and only they can go to the release branch. > This > >>>> can be > >>>>>>>>>>>> done through jira and with certain rules.(may be using jira > vote?) > >>>>>>>>>>>> this would save the cherry-picking time and another branch > >>>>>>>> maintenance. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Please add your thoughts/suggestions/comments. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Ref: > >>>>>>>>>>>> > >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html > >>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0 > >>>>>>>>>>>> > >>>>>>>>>>>> ~Rajani > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> *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>*™* > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> *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 > > -- *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>*™*
