cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Tue, 08 Jul 2014 10:30:30 GMT
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 <bhaisaab@apache.org> wrote:
> Hi,
>
>
> On Tue, Jul 1, 2014 at 3:39 AM, Sebastien Goasguen <runseb@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.Karuturi@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 <shadowsor@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.Karuturi@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.Karuturi@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.tutkowski@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.Turner@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.tutkowski@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.Karuturi@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.tutkowski@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.tutkowski@solidfire.com
>> >>>>> o: 303.746.7302
>> >>>>> Advancing the way the world uses the cloud
>> >>>>> <http://solidfire.com/solution/overview/?video=play>*(tm)*
>> >>>>
>> >>>
>> >>>
>> >
>>
>>



-- 
Daan

Mime
View raw message