cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Schmit <sam.sch...@appcore.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Tue, 29 Jul 2014 15:00:17 GMT
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" in order to prepare a
release candidate branch.  "Hotfix" branches can be made off of a release
branch to fix any final issues.
*  Standard gitflow would then have the "release" branch merge into master,
which would contain only release-ready versions of the code.

I've followed this project workflow for several projects, and it seems to
work well.  Once we get everyone accustomed to this, I think it will
improve everyone's ability to follow along with what is happening in the
project, and will help project coordinators keep control of the overall
direction.

Sam





On Mon, Jul 28, 2014 at 11:03 AM, Rohit Yadav <rohit.yadav@shapeblue.com>
wrote:

> 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.hoogland@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<terbolous@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.Karuturi@citrix.com>
>>>> følgende:
>>>>
>>>>  On 24-Jul-2014, at 10:25 pm, Mike Tutkowski<mike.tutkowski@
>>>>> 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.Karuturi@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.hoogland@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.Karuturi@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.tutkowski@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.hoogland@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<
>>>>>>>>>>>
>>>>>>>>>> runseb@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen<
>>>>>>>>>>>> runseb@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon<
>>>>>>>>>>>>>
>>>>>>>>>>>> nate.gordon@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<
>>>>>>>>>>>>>>
>>>>>>>>>>>>> runseb@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  On Jul 23, 2014, at 11:38 AM, daan
Hoogland<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> daan.hoogland@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<
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jul 23, 2014, at 11:19
AM, Sam Schmit<
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sam.schmit@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message