cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <Rajani.Karut...@citrix.com>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 06:29:04 GMT
I am just wondering if the shift to a new develop branch is causing the problems. Its a simple
branch shift and should be no different from the current master.

may be we should leave the master as is and create a ‘stable' branch which would act like
master in git-flow ?

ie) 
ACS master -> develop in git-flow
ACS stable -> master in git-flow 


~Rajani



On 06-Aug-2014, at 10:56 am, Daan Hoogland <daan.hoogland@gmail.com> wrote:

> Hello devs and especially committters,
> 
> I see some -1s coming by, days after the vote was closed. That is
> disturbing as it means we accepted a proposal that will not be
> supported by the community. So let me try to find that support in
> hindsight;
> 
> The argument of Animesh that we are shifting the burden from one
> branch to another is real and present danger. I share his concern. It
> is not the only feature of this proposal and in it self does not
> warrant a -1. It does not worsen the situation at hand or add to our
> workload in any way. If there is no advantage to you and no
> disadvantage either then why -1 something that others do find useful?
> This is 'kind of' a rhetorical question. It is a real concern, however
> though not the biggest at this moment.
> 
> branching is recommended but as people are rightfully wondering
> "should I make a branch for a single line fix". I would, probably but
> maybe not always. That doesn't mean you must. In case you are making a
> fix on a release then yes you do. It is how the git-flow workflow
> goes.
> 
> Committers can merge and commit where ever they feel the need. That
> doesn't exempt them from thinking if it is a good idea. It doesn't now
> and it won't in the future. Doing what your boss tells you to do can
> be a crime!
> 
> Reverting something should only be done when the code that is a
> culprit has been identified. Reverting a big change or even a bunch of
> changes is a cowards way out. We shouldn't do it now or using gitflow.
> It is not really related to git flow or its use. So we shouldn't
> penalize developers that didn't cause a problem or ones that did. We
> should help them help us make a better system.
> 
> The question of why this process isn't implemented on master is valid.
> It could. It isn't however. It is a choice the authors of gitflow
> made. I think it is not really the time anymore to be nitpicking about
> this. Unless we find a very valid reason to alter the accepted
> proposal we should all try and implement it as good as possible. I
> have been RM for 4.4.0 and one thing I don't want anymore is people
> share a 4.4-forward to cherry-pick commits from. It caused me a lot of
> headaches.
> 
> The release is what drives the merges back to master according to
> git-flow. We can decide that we define a number of prerelease dates at
> which we merge as well. We don't have to do it at that date but can
> decide to do that the next day or week as well. This would kind of
> resemble Alena's #1 (as opposed to the more pure gitflow #2). An
> argument for #2 is that I don't think every customer greps the rpms
> for some release. I know our operators at Schuberg Philis investigate
> the code and check it out from git. They like to compare release and
> look at the latest easily. just checking out master would be very
> convenient for them. Of course they can check out a branch as well.
> But I doubt if they know exactly what to checkout then. I usually see
> them just look at the latest for a branch.
> 
> All in all, I am very skeptic on whether this will work as planned. It
> is us who need to work neatly and only if we do that we can help
> ourselves with improving our process. I do feel that the present way
> of working, mainly the use forward branches but in general the lack of
> using branches to test individual changes, is hindering us in doing
> releases. The proposal at hand is very good but can only work if
> supported by the people that need to work with it. It doesn't do our
> release process for us. We still need to do it and not just program
> some code and check it in. That will never work in any process. Your
> code is not done until somebody somewhere finds it worth running it in
> a production environment. So let's keep discussing and educating each
> other.
> 
> done ranting, feel free to react or contact me in person
> Daan
> 
> 
> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <david@gnsa.us> wrote:
>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <terbolous@gmail.com> wrote:
>> 
>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <Prachi.Damle@citrix.com>
>>> wrote:
>>> 
>>>> I fail to understand how will this model help us with the maintenance
>>>> releases?
>>>> 
>>>> 
>>> That's what gitflow support branches is for.
>>> I find this quite descriptive:
>>> 
>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
>>> 
>>> 
>>> 
>>>> For CloudStack we also keep working on prior releases and ship out
>>>> maintenance releases.
>>>> I suppose we will be cutting the maintenance releases from the release
>>>> branches? So we will have to keep around the release branches for that
>>>> purpose.
>>>> 
>>>> 
>>> I've asked earlier, but what is the policy on old releases? How long do we
>>> support them?
>>> 
>>> 
>> Today (e.g. subject to change) we claim to support as a community the two
>> most recent feature releases. (for instance, we just stopped support the
>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and
>> 4.4.x) We support those feature releases with bug fix releases that contain
>> no additional functionality.
>> 
>> --David
> 
> 
> 
> -- 
> Daan


Mime
View raw message