Rohit, I agree with most and I am glad to see you prefer cherry-pick over merges. I do not see why the PMC should drive defining the standard. This is something that should be carried and cherished by all developers.
On Tue, Jul 8, 2014 at 9:51 AM, Rohit Yadav <bhais...@apache.org> wrote: > Hi, > > > On Tue, Jul 1, 2014 at 3:39 AM, Sebastien Goasguen <run...@gmail.com> wrote: > >> I would like to re-start this discussion. >> > > Such a shame, this is not getting any attention. > > >> >> 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. >> > > I think too that this is going to take time, meanwhile a great way would be > to self police? > > I would encourage every committer at least to learn to use git, handle git > mess-ups, have a knowledge about various ACS 4.x branches, favour squashed > commits and cherry-picking over branch merges, rebase on target branch > (master) regularly, build often with unit tests before pushing to master > (at least), test patches on local before merging them on master and other > branches. > > @PMC: suggestion -- help drive defining a convention on committer workflow > (refer nvie etc.), make it a requirement for all the committers (future and > present) to learn/know (basic/novice) git, have knowledge about various ACS > branches and release processes. > > Comments, suggestions? > > Regards. > > >> >> 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>*(tm)* >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> *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>*(tm)* >> >>>> >> >>> >> >>> >> > >> >> -- Daan
