Hi,
This thread summarizes gitflow and the git process talk Rajani shared
with us in the other thread:
http://markmail.org/message/4hk2jwvxt4lcpqig
This is what Rajani shared during the end of the thread:
http://markmail.org/message/2642ilfajkpshnfn
After reading 58 emails on the original thread, here what I've to
suggest and discuss:
- adapt the "gitflow" to our workflow, we don't need to enforce it or
its esoteric concepts
- have a stable master because everyone ends up using master including
the new contributors
Feature development and bug fixes:
- work on a branch checked out from master or release branches
- don't commit on master by default, only if you're sure and have passed
by success builds and tests
Backporting changes: (from one branch to other branch/release)
- don't cherry pick if there are too many commits (say 50+) instead I
recommend using branching & merging
- in case of feature work/refactoring and work that results in a lot of
conflict, use squash merging that results in few revert-able commits
Open ended questions:
- How do we have a workflow that supports backporting changes/features
to old releases say 4.0, 4.1 etc.
- How do we insure this is well communicated to everyone and everyone
follows what we'll agree by vote or scout's honor
- For merging any feature work or branch or cherry-picking commits to
master do we need to have a review requirement using reviewboard etc?
Regards.
Daan Hoogland wrote:
Let me explain a little more about this lat mail of mine.
I was assuming a lot of context that most people may not have.
We want to start working differently with respect to our release
procedure and branching habits. The proposals that are out there and
about to be voted for are going to require a lot of work of a few
people and a lot of discipline from all of us.
My idea was to first vote for some of the habits that are part of the
gitflow discipline, but I am not strong opinionated about that.
I do want to prevent that we go for a grand proposal to completely
change our way of moving forward (not just the way we move forward)
while there are potentially people opposing to this way of working.
So please give a +1/0/-1 to the general idea now, so we fell
comfortable spending the time in devising a new release
schedule/mechanism.
some of the highlights are:
it will start with 4.5 (4.4.x will be done with the old manual
cherry-pick process)
it will require everybody to create a branch for every fix or feature
they will contribute.
it will require devs to work mainly on a new branch call 'develop'
it will be every bodies responsibility to ensure that 'master' is at
all times releasable
thanks,
Daan
On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland<daan.hoogl...@gmail.com> wrote:
I am not for a grand proposal but ok, I can live with it.
It would be easiest to just vote for using the gitflow model.
Leo is preparing a page on how to do it. I don't know what the status
is on it. The vote for my part would be on the contents of that page.
On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
<mike.tutkow...@solidfire.com> wrote:
Yeah, I was under the impression this decision would require a vote and
formal announcement, if it passes.
On Monday, July 28, 2014, Hugo Trippaers<h...@trippaers.nl> wrote:
Agreed, this kind of important decisions should be made by a vote.
Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
condensed summary of the thread?
Cheers,
Hugo
On 28 jul. 2014, at 14:07, Ian Duffy<i...@ianduffy.ie<javascript:;>>
wrote:
+1 to what Erik said.
On 28 July 2014 13:04, Erik Weber<terbol...@gmail.com<javascript:;>>
wrote:
On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland<daan.hoogl...@gmail.com
<javascript:;>>
wrote:
H,
I see a lot of commits happening directly on the master branch. Yet
there were no counter arguments against the proposed gitflow and the
discussion around it. This leaves me with the idea that the thread is
largely ignored by the community. It is my understanding that we
agreed never to commit anything to master anymore that hasn't been
first committed to a branch and is merged back to master (instead of
cherry-picked). What mistake in thinking am I making here?
Not familiar with bylaws and the such, but wouldn't a change like this
require some sort of voting and potentially a more formal information?
Requiring everyone to read through a 50+ replies mail thread and
comprehend
it could be a bit much.
I would suggest an updated document that explain the expected workflow.
--
Erik
--
*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.
