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
Hi,
It took me sometime to go through all the 58 emails on this thread.
I suggest we need to adapt "gitflow" to our git workflow. I liked the
summary Rajani suggested here: http://markmail.org/message/2642ilfajkpshnfn
Let's continue the discussion in the new thread now:
http://markmail.org/messa
That seems to handle my concern :-)
Erik
25. juli 2014 13:16 skrev "Rajani Karuturi"
følgende:
> branches will be deleted after the release or hotfix if you use the
> git-flow commands.
>
> This would be the flow for a hotfix:
> 1. branch off from the release tag on master. in this case it would
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
branches will be deleted after the release or hotfix if you use the git-flow
commands.
This would be the flow for a hotfix:
1. branch off from the release tag on master. in this case it would be
release/4.4.0
2. commit the fixes in hotfix/4.4.1
3. do the release
4. merge to develop
5. merge to
I went on and read the comments in
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
It contains a big warning on using gitflow that has been between my
lines in this thread all along. Git flow is not going to solve our
problem. It is a discipline that is captured in it that will
Rightful question Erik,
Rajani mentioned that release branches will be deleted. This will only
happen once the release is no longer supported. Any hotfix branch will
still have to merged on that (and master possibly) until we stop
supporting that branch.
On the other hand you can branch from any
This is out of my git league, but how do you handle minor versions that way?
Assuming 4.8.0 is the latest stable release and HEAD on master.
Then you want to release 4.4.1.
First of all can you develop bugfixes for 4.4 along the way, when both
develop and master HEAD might be hugely different?
I suppose we need a formal VOTE on this?
If so, perhaps Sebastien would like to call it.
On Thu, Jul 24, 2014 at 10:06 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Great. Well, this seems reasonable to me then.
>
> If there are no objections or further comments, when can this be
Great. Well, this seems reasonable to me then.
If there are no objections or further comments, when can this be done and
who would do it?
Thanks
On Thu, Jul 24, 2014 at 10:01 PM, Rajani Karuturi <
rajani.karut...@citrix.com> wrote:
> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski
> wrote:
>
> >
On 24-Jul-2014, at 10:25 pm, Mike Tutkowski
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 al
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?
Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
into RELEASE-4.5?
On Thu, Jul 24, 2014 at 12:39 AM,
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
Hi Daan/Erik,
I am not asking about the next minor release or hot fix. But, about the process
involved after cutting the release branch and before the release is votes.
i.e.) making it stable and bug/blocker free.
currently, we do that through commit to 4.5-forward and cherry-pick requests.
Are
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
24. juli 2014 08:39 skrev "Rajani Karuturi"
følgende:
>
>
> 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 br
That's where the 4.5-hotfixes branch comes in.
On Thu, Jul 24, 2014 at 8:39 AM, Rajani Karuturi
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 onc
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 th
24. juli 2014 06:28 skrev "Rajani Karuturi"
følgende:
>
> 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 s
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,
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 sam
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:
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 -hotfixes
as transition we will
Right, 'master' should - theoretically - be somewhat stable at present as
we are post 4.5 Feature Freeze.
I guess we should address Daan's question of what 'develop' means in this
new model? When can code be checked into 'develop', but not 'master'? Code
that goes into 'master' must be deemed 'sta
Must it start today, or when (if) the vote passes? Feature freeze for 4.5
has theoretically passed, so basically master branch should now be work in
progress towards a stable branch.
So I'd say; create a 'develop' branch off the current master.
Keep master as is, and only merge bugfixes until it
On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen wrote:
>
> On Jul 23, 2014, at 12:21 PM, Nate Gordon 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 d
On Jul 23, 2014, at 12:21 PM, Nate Gordon 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 i
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
wrote:
> To start this a
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
c
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 sta
On Jul 23, 2014, at 11:38 AM, daan Hoogland 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 for
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. T
On Jul 23, 2014, at 11:19 AM, Sam Schmit 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 soluti
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 weakne
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/workfl
On 01/07/14 3:39 am, "Sebastien Goasguen" 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. How
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
On Jul 8, 2014, at 2:20 PM, Nate Gordon wrote:
> As someone who has worked with a number of different version control
> systems (and have far more love for git than any other), I'm curious as to
> why we would want to fight what I've always seen as the core feature of
> git. Branching and mergin
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
As someone who has worked with a number of different version control
systems (and have far more love for git than any other), I'm curious as to
why we would want to fight what I've always seen as the core feature of
git. Branching and merging. The gitflow model is incredibly useful for
keeping trac
Thanks for bringing this up again, Sebastien.
I've had http://nvie.com/posts/a-successful-git-branching-model/ up in
Chrome since you sent that link and been reading through it a bit here and
there, but have just been too busy as of late to give it a bunch of thought.
I agree, though, that we sho
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 wrote:
> Hi,
>
>
> On Tue, Jul 1, 20
Hi,
On Tue, Jul 1, 2014 at 3:39 AM, Sebastien Goasguen 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/
>
> Thinkin
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
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.
i
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
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 ar
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 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
66 matches
Mail list logo
