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/message/zf5yt47jqq3auswo
Regards.
Rajani Karuturi wrote:
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 master and update tags
6. delete hotfix branch
But, I agree that there can be a problem when we wish to do 4.4.2 if we delete
the hotfix branch
may be we should use git-flow support instead of hotfix which doesn’t delete
the branch
http://stackoverflow.com/a/16866118/201514
~Rajani
On 25-Jul-2014, at 12:31 pm, Daan Hoogland<daan.hoogl...@gmail.com> wrote:
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 commit.
btw 4.4.1 is a bad example of you as we will still maintain that
without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber<terbol...@gmail.com> wrote:
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?
Second, can you commit behind HEAD? You don't want the 4.4.1 release
instead of 4.8.0 to be HEAD
Someone might have good solutions to this, but if not I would propose to
keep the release branches for future bugfixes.
Erik
25. juli 2014 06:02 skrev "Rajani Karuturi"<rajani.karut...@citrix.com>
følgende:
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>*™*
--
Daan
--
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure
Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those of
Shape Blue Ltd or related companies. If you are not the intended recipient of this
email, you must neither take any action based upon its contents, nor copy or show
it to anyone. Please contact the sender if you believe you have received this email
in error. Shape Blue Ltd is a company incorporated in England & Wales.
ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue
SA Pty Ltd is a company registered by The Republic of South Africa and is traded
under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
