On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote:
> I believe I agree with these steps. > > A couple questions: > > Is 'master' simply always going to be equal to what's the most recent > version of the code that's in production? I think so. master will always be at the latest release and all the previous releases properly tagged. The release branches would be deleted once release is done. > > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly > into RELEASE-4.5? > Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes should be done on the 4.5 branch. ~Rajani > > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi < > rajani.karut...@citrix.com> wrote: > >> >> Hi Daan, >> here is what i propose: >> >> 1. rename 'master' to 'develop’ >> 2. branch a new 'master' from '4.4’ >> 3. branch 'RELEASE-4.5' from the develop >> 4. merge 'RELEASE-4.5' to master once the release voting is done. >> >> RELEASE-4.6 branch should be off develop as all the feature branches would >> be merged there before freeze for 4.6 and would be merged to master when >> the release is voted. >> >> The other question I have is in the step:4. how are we going to manage >> fixes to 4.5 post branch cut? ( assuming no features as the freeze is done) >> >> ~Rajani >> >> >> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >> >>> Mike, Rajani, >>> >>> Sebastien's point was that the current 4.4 is the closest we have to a >>> releasable branch. I don't mind enting on master but it will require >>> more fixing. In general all of this will require some RM work of all >>> committers. Please ammend my little proposal if you will. >>> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi >>> <rajani.karut...@citrix.com> wrote: >>>> I agree with mike. I think we should start 4.5 from where master is now >>>> Also create a develop branch from master and continue future work for >> 4.6 there. >>>> >>>> I am not clear on how the release branches are going to be maintained. >>>> Are we saying we would create 4.5-RELEASE branch which is essentially >> same as our current -FORWARD branch and continue cherry-picking? >>>> >>>> I would prefer merges to cherry-picks. >>>> Also, I think we should allow committers to commit to the RELEASE >> branch after discussing about it on dev@ and have RM closely monitor them. >>>> Any commit intended for 4.5 RELEASE should be checked in after >> discussion in the 4.5 Release branch and then merged to develop branch. >>>> >>>> >>>> ~Rajani >>>> >>>> >>>> >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >>>> >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left >> off >>>>> and then merge features from develop into 4.5. >>>>> >>>>> Why don't we instead start 4.5 where master is now with the assumption >> that >>>>> since we are past Feature Freeze for 4.5 that master is stable enough? >>>>> >>>>> >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland < >> daan.hoogl...@gmail.com> >>>>> wrote: >>>>> >>>>>> so to start formulate a proposal: >>>>>> >>>>>> all work shall be done in a new branch (it is advisable to prefix your >>>>>> branches with your id) >>>>>> when working, features will be cherry-picked/merged into the release >>>>>> branch they are for and next into master. >>>>>> hotfixes will be done in <branchname>-hotfixes >>>>>> >>>>>> as transition we will >>>>>> >>>>>> rename 'master' to 'develop' >>>>>> branch a new 'master' from '4.4' >>>>>> branch '4.5' from the new 'master' >>>>>> merge any features from the new 'develop' to '4.5' and 'master' >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <run...@gmail.com >>> >>>>>> wrote: >>>>>>> >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <run...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <nate.gor...@appcore.com> >>>>>> wrote: >>>>>>>> >>>>>>>>> Let me ask the question, why have master be develop and a release >>>>>> branch be >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick >> with >>>>>> the >>>>>>>>> norm? If master is the development branch, it might not be stable. >> I >>>>>> think >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone >> could >>>>>> come >>>>>>>>> check out master and have the latest useable. >>>>>>>> >>>>>>>> I am in favor of following the norm, so ideally master should be our >>>>>> stable branch (agreed). >>>>>>>> >>>>>>>> The issue is with the transition. >>>>>>>> >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so >> ideally >>>>>> we could start a stable branch of this tag and build up bug fix >> releases >>>>>> all the way to 4.5 from there. >>>>>>>> >>>>>>>> But all features for 4.5 are already in master. >>>>>>>> >>>>>>>> So if we create a 'develop' branch of master and stabilize 'master' >>>>>> then develop is now started from a stable tag (4.4.0). >>>>>>>> >>>>>>> >>>>>>> *not* started from a stable tag, and merges will be tricky, no ? >>>>>>> >>>>>>>> So what's the best way to flip ? There is most likely some git magic >>>>>> that can we do. >>>>>>>> >>>>>>>> >>>>>>>> The new git workflow and the transition process need to be part of a >>>>>> proposal that we get consensus on. >>>>>>>> >>>>>>>> getting there :) >>>>>>>> >>>>>>>> -seb >>>>>>>> >>>>>>>>> >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If >> you >>>>>>>>> completely squash history, you lose a tremendous amount of context, >>>>>> which I >>>>>>>>> use extensively to figure out why a bug is the way it is. Only >> knowing >>>>>> that >>>>>>>>> the branch was merged at a given point in time doesn't give any >>>>>> context. >>>>>>>>> Seeing the individual commit history of the branch helps to >> preserve >>>>>> the >>>>>>>>> rationale for why the code was written the way it was. In theory if >>>>>> every >>>>>>>>> change starts out as a branch (feature, hotfix, release), then why >> not >>>>>> just >>>>>>>>> merge the branch once it is in a good and acceptable state? >>>>>>>>> >>>>>>>>> I also agree with Mike that this will have to be a transition over >>>>>> time. It >>>>>>>>> will take some time to clean up master to the point where it can be >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5 >> release. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 23, 2014 at 10: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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> *Nate Gordon*Director of Technology | Appcore - the business of >> cloud >>>>>>>>> computing® >>>>>>>>> >>>>>>>>> Office +1.800.735.7104 | Direct +1.515.612.7787 >>>>>>>>> nate.gor...@appcore.com | www.appcore.com >>>>>>>>> >>>>>>>>> >> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> The information in this message is intended for the named >> recipients >>>>>> only. >>>>>>>>> It may contain information that is privileged, confidential or >>>>>> otherwise >>>>>>>>> protected from disclosure. If you are not the intended recipient, >> you >>>>>> are >>>>>>>>> hereby notified that any disclosure, copying, distribution, or the >>>>>> taking >>>>>>>>> of any action in reliance on the contents of this message is >> strictly >>>>>>>>> prohibited. If you have received this e-mail in error, do not >> print it >>>>>> or >>>>>>>>> disseminate it or its contents. In such event, please notify the >>>>>> sender by >>>>>>>>> return e-mail and delete the e-mail file immediately thereafter. >> Thank >>>>>> you. >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >> >> > > > -- > *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>*™*
