cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: implementing git workflow
Date Tue, 05 Aug 2014 18:51:08 GMT
I think we should hold on with the git workflow implementation till all
the decisions on the items written by Leo, are discussed and finalized.

The very beginning of ³git workflow vote² shows that the vote was just to
get people opinion on the proposal. Before adopting it and cutting the
develop branch, all the questions should be cleared out.


"Rohit Yadav

+1

Hugo, I think we started this voting thread to get opinion on the
proposal. I feel it may need some iteration and community agreement before
we adopt it.

Suggestions, flames and opinions are welcome.

Regards.


On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hugo@trippaers.nl> wrote:

>Rajani,
>
>To make it clear for everyone. This is the vote to adopt this new way of
>working right? Or is it just to get an opinion on the proposal?
>
>If it is indeed the vote to adopt this way of working it means that all
>committers will change how we interact with the branches in the
>CloudStack git.
>
>It¹s is a good thing in my book, but we need to be clear what the
>expected result is when this vote has concluded in 72 hours.
>
>Cheers,
>
>Hugo
"


-Alena.



On 8/4/14, 6:59 AM, "Leo Simons" <LSimons@schubergphilis.com> wrote:

>Hey folks,
>
>Since Daan volunteered me to do some docs, I¹ve updated Rohit¹s page at
>    https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
>
>with additional details.
>
>I went back through all the e-mails on the subject to find
>questions/concerns, addressed the ones I think have consensus and
>highlighted a few places where additional decision/discussion may be
>needed.
>
>Remaining topics I¹m not sure about:
>* when to cut over
>* how to cut over
>* policy for who merges to release branches
>* policy for adding features in micro releases
>* what to name hot fixes
>
>Comments on each below.
>
>When to cut over
>----------------
>I think docs are quite sufficient now. I¹d personally suggest to just do
>it.
>
>Since the vote is done I think any committer should feel free to pick up
>the ball :)
>
>How to cut over
>---------------
>* Someone has to make the branches and announce the flip on the mailing
>list.
>* Everyone has to flip / git flow init / etc.
>* Someone has to update jenkins.buildacloud.org to build the new develop
>branch.
>* ???
>* Profit.
>
>Again, I¹d personally suggest to just do it.
>
>Policy for who merges to release branches
>-----------------------------------------
>There was some unresolved discussion about
>1. when it is ok to directly commit to the release branch
>2. when it is ok for other people than the release manager to merge to
>the release branch
>3. when/how to do a freeze of a release branch
>
>Git flow says:
>1. basically never
>2. what¹s a release manager?
>3. never, cut release branch == feature freeze, tag release == freeze
>
>Personally I would suggest
>1. never unless you are doing release management (i.e. version bump)
>commits
>2. always as long as you are confident and prepared to suffer the wrath
>of doing it wrong, ask the release manager to do it if you are not
>confident
>3. at the jurisdiction of the release manager
>
>Policy for adding features onto release branches
>------------------------------------------------
>It has been cloudstack practice to include new features (or enable
>features) in micro releases.
>
>I did document how to do this within the git-flow model, but I strongly
>suggest to simply stop doing it.
>
>I suggest the policy is that this can be done as an exception to the rule
>after discussion on the mailing list, using lazy consensus, with the
>release manager doing the merge to the release branch.
>
>what to name hotfixes
>---------------------
>hotfix/<jira-ticket>
>
>the -<summary> should be descriptive and is optional.
>
>hotfix/4.4-<jira-ticket>
>
>for fixes to 4.4.x.
>
>
>
>cheers,
>
>
>
>Leo
>


Mime
View raw message