Mike, Why not then just rename master to develop? people can still commit to it. We don't need to have a branch named master and we can name any branch so. in line with the gitflow article we could fork master of off 4.4...
On Wed, Jul 23, 2014 at 6:13 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > 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>*™* -- Daan
