I just got caught up on this. My apologies for the delay.
I think that we are very much on the right track and that we are right to
deviate from the normal gitflow concept around the maintenance versions.
Since we will in theory have a 4.5.1 after 4.6.0 is released, there will be
some level of con
Hey guys,
I totally agree that going with a git workflow is the best way forward:
* Having developers branch off of "development" onto a bugfix/feature
branch to add or fix something in cloudstack, and controlling the merge
back into "development".
* Using a "release" branch off of "development
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
ver
t;>>>>>>> Or maybe I am not reading your mail right and you don't
> agree
> >>>>> with
> >>>>>>>>> Leo ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>&
On Fri, Jul 25, 2014 at 1:16 PM, Rajani Karuturi
wrote:
> may be we should use git-flow support instead of hotfix which doesn’t delete
> the branch
Good call Rajani
--
Daan
gt;>>>>>>> with that).
>>>>>>>>>>>>>>> That means that development should not happen on master and
>>> that
>>>>>>>>> every
>>>>>>>>>>>
le.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be
>>> >> fine
>>> >>>>>>>>>> cherry picking fro
ntial
>> >>>>>> bug.
>> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>> >> previous
>> >>>>>>>>>> release branches.
>> >>>>>>>>>>>>
>
>> for
> >>>>>> a
> >>>>>>>>>> vote.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
> and
> >> how
> &
dev work and
>> >> potential
>> >>>>>> bug.
>> >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
>> >> previous
>> >>>>>>>>>
t;>>>>>>>> vote.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process
> and
> >> how
> >>>>>> we
> >>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
>> implement
>>>>>> t
gt;
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>
> >>>>>
daan.hoogl...@gmail.com]
> Sent: 24 July 2014 17:30
> To: dev
> Subject: Re: [DISCUSS][PROPOSAL] git workflow
>
> On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips
> wrote:
> > Good read
> > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
>
: Re: [DISCUSS][PROPOSAL] git workflow
On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips wrote:
> Good read
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
he agrees with our thread that every work sould start with creating a branch,
doesn't he. I think we need to
Yes, that is what he is saying. Its really the git way.
Starting a branch with the ticket-id and short description works best.
I think this is what you are looking for
https://wiki.diasporafoundation.org/Git_workflow
On Thu, Jul 24, 2014 at 12:29 PM, Daan Hoogland
wrote:
> On Thu, Jul 24, 201
On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips wrote:
> Good read http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
he agrees with our thread that every work sould start with creating a
branch, doesn't he. I think we need to say that a lot of times more.
Start a new branch when
The best thread I have read in awhile...
Good read http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
On Thu, Jul 24, 2014 at 8:06 AM, Daan Hoogland
wrote:
> On Thu, Jul 24, 2014 at 1:43 PM, Leo Simons
> wrote:
> > lsimons
>
>
> has access
>
> --
> Daan
>
On Thu, Jul 24, 2014 at 1:43 PM, Leo Simons wrote:
> lsimons
has access
--
Daan
On Jul 24, 2014, at 1:19 PM, Daan Hoogland wrote:
> Leo, are you prepared to write up a how-to cwiki page?
Sure, though it would be good to get a few provisional +1s before spending a
lot of time drawing pretty pictures :)
Also, I don’t seem to have edit permissions on
https://cwiki.apache.org
It makes sense to me now. +1 from me
one minor thing i would like to add is git-flow doesn’t force you to its naming
convention. You can choose any and stick to it. But, it makes sense to use the
defaults.
~Rajani
On 24-Jul-2014, at 2:52 pm, Leo Simons wrote:
> On Jul 24, 2014, at 10:45 AM
now we are kind of set back by this unfortunate result of Leo's work.
new proposal:
We start using git-flow for 4.5/5.0 exclusively.
as of then we will use the workflows as describe by him [1]
4.4.x will still be released by manual RM-cherry-picking (yes
volunteer dragging his feet)
Leo, are you
On Jul 24, 2014, at 10:45 AM, Daan Hoogland wrote:
> Any advice on our procedure from this, Leo?
Yes, to follow all the git-flow defaults [1].
* goal is for master to become stable
* new develop which starts from master
* create with `git flow init`
* ‘abandon’ 4.4 / 4.4-forward
* anything i
ire.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
branc
Any advice on our procedure from this, Leo?
On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons wrote:
> On Jul 24, 2014, at 8:39 AM, Rajani Karuturi
> wrote:
>> 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 dev
On Jul 24, 2014, at 8:39 AM, Rajani Karuturi wrote:
> 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.
I like this conceptually; I’m not
>>>>>>> stuff
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> t
t;>>>>
>>>>>>>>>>>>> which might be easier to read.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with implementing
>>>>>
tps://www.atlassian.com/git/workflows#!pull-request
>>>>>>>>>>>>
>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in support
>>>> for
>>>>>>>>>>>> git-flow
>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Leo
> >>>>>>>>>>
> >>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
run...@gmail
;>>>>>>>>> forward.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> cheers,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
Gitflow:
>>>>>>>>>>>
>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>>>>>>>>
>>>>>>>>>>> Thinking about our release procedure, we clear
ch 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.
> >>>>>>>>>
>
gt;>>>>>>>>
>>>>>>>>> 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 o
gt; freezes master. Development happens in a 'develop' branch,
> releases
> > >>>>>> branches are branched off of that and merged into master and back
> > into
> > >>>>>> develop….etc
> > >>>>>>>
> &g
gt;>>> wrote:
> >>>>>>>
> >>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>> As a contributor, I always endup creating multiple patches for
> each
> >>>>>> branch as they
;>>>> 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 com
t;>>>>>>>
>>>>>>>> ~Rajani
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus wrote:
>>>>>>>>
>>>>>>
se on top of it should be a painless merge.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ~Rajani
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 02-
rging). 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
> >>>>>>>
gt; >>>>>>> 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&
;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
>>&
gt; 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.c
t;>>
>>>>>>
>>>>>> ~Rajani
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>> rajani.karut...@citrix.com>
>>>>>> wrote:
>
r a major rewrite, we
> >>>> could stop merging to that branch and above and make the fix manually.
> >>>>>
> >>>>>
> >>>>> ~Rajani
> >>>>>
> >>>>>
> >>>>>
> >>>>> On
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
>>>> th
gt; 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 b
Hi,
Rajani Karuturi wrote:
In my first email, I mentioned a youtube url[1] which is a google tech talk by
Laura Wingerd [2] of Perforce Software
I recommend watching it as well. (its a 55 min video).
[1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
[2] http://www.perforce.com/blog/author/lwing
In my first email, I mentioned a youtube url[1] which is a google tech talk by
Laura Wingerd [2] of Perforce Software
I recommend watching it as well. (its a 55 min video).
[1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
[2] http://www.perforce.com/blog/author/lwingerd
~Rajani
On 09-Jul-2014
On Jul 8, 2014, at 5:40 PM, Sebastien Goasguen wrote:
>
> On Jul 8, 2014, at 4:13 PM, Rohit Yadav wrote:
>
>> Hi Chip,
>>
>> Chip Childers wrote:
>>> Let me try that again, this time with content!
>>>
>>> I've dropped private@, since this doesn't belong there.
>>>
>>> On Tue, Jul 8, 2014 a
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,
On Jul 8, 2014, at 4:13 PM, Rohit Yadav wrote:
> Hi Chip,
>
> Chip Childers wrote:
>> Let me try that again, this time with content!
>>
>> I've dropped private@, since this doesn't belong there.
>>
>> On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav
>> wrote:
>>> Hi,
>>>
>>>
>>> Daan Hoogland
Hi Chip,
Chip Childers wrote:
Let me try that again, this time with content!
I've dropped private@, since this doesn't belong there.
On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav wrote:
Hi,
Daan Hoogland wrote:
I do not see why the PMC should drive defining the
standard. This is something t
Let me try that again, this time with content!
I've dropped private@, since this doesn't belong there.
On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav wrote:
> Hi,
>
>
> Daan Hoogland wrote:
>>
>> I do not see why the PMC should drive defining the
>> standard. This is something that should be carrie
On Tue, Jul 8, 2014 at 3:30 PM, Rohit Yadav wrote:
> Hi,
>
>
> Daan Hoogland wrote:
>>
>> I do not see why the PMC should drive defining the
>> standard. This is something that should be carried and cherished by
>> all developers.
>
>
> In my experience when something is everyone's responsibility,
Hi,
Daan Hoogland wrote:
I do not see why the PMC should drive defining the
standard. This is something that should be carried and cherished by
all developers.
In my experience when something is everyone's responsibility, eventually
no one is responsible for it.
I think the PMC should drive i
rging to that branch and above and make the fix
> manually.
> > >>>>
> > >>>>
> > >>>> ~Rajani
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 30-May-2014, at 11:26 pm, Mike T
>>
> >>>>
> >>>> 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
> >>>
gt;> 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
>> >>>>
>> >>>
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
> >>> the
t;>> 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:
>>>&
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
Is that not happening?
On Mon, Jun 2, 2014 at 11:26 AM, David Nalley wrote:
> On Mon, Jun 2, 2014 at 1:21 PM, Marcus 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 bac
On Mon, Jun 2, 2014 at 1:21 PM, Marcus 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 becaus
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 af
nged? 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]
>>> Se
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
n 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.
>
ike.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
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
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 differ
71 matches
Mail list logo
