On 08/15/2014 12:25 PM, Rohit Yadav wrote:
Hello everyone,
With reference to my proposal on changing our release-master commit flow [1], I
would like to start a voting thread to decide on the adoption starting 4.5
release. Any opinion, ideas, modifications is welcome to help reach a consensus
and improve our present situation.
Today’s Friday so it will be only fair to extend the voting window to more than
our usual 72 hours window.
Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H UTC
giving about 5 days of time for people to share what works and what does not.
We’ll stop anytime we've three -1s (binding).
Short summary:
- Base line protocol: Continuous changes from release/stable branches to
master/unable branches
- Get contributors more engaged with release branches by working (fixing bugs,
docs etc.) on release branches first (and not on master)
- Fixes on release branches are recommended (non strict enforcement) go via a
hotfix/bugfix branch that get automatically tested by Jenkins, when they are
green RMs get the changes to release branch
Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as this
may change/modify in this thread)
- Continuous flow of changes from stable branches to un-stables ones i.e. from
release branches to master and from master to features etc. Use of merge
—fast-forward is encourages over cherry-picking and —no-ff (no ff will create
merge commit). This happens couple of times a day to ensure we get solid/robust
changes from release branches (such as bugfixes etc.) on master, any conflicts
will be resolved. If we do it continuously we’ll also save ourselves from a big
conflict at the end of the release cycle and we’ll also avoid
missing/misplacing any commit when cherry-picking.
- After code freeze is declared and release branch is cut out, contributors
work on fixing bugs and other changes (such as documentation, build/packaging
fixes etc.) first on the release branch (and not master). This is not to
restrict anyone working on master, features and other changes can keep landing
on master as well. This is to encourage contributors to give more attention to
release branches by at least fixing bugs on release branches first and not our
current way where we fix it on master and ask RMs to cherry pick it to release
branch.
- Changes to release branches can be done by pushing a bugfix/change branch and
asking the RM to pick it up if they are tested. Our automated systems can
perform checks on such branches too (starting with a suffix that can
automatically trigger such builds/tests) and if everything is fine, RMs to land
the changes to release branches.
- Nothing is written in stones, this should be change-able. And, this can only
work if we all agree to follow this with 4.5
To make the best of this thread, please keep your reply short, constructive and
to the point..
Please share your opinion on this proposal with suitable reasons:
[ ] +1 approve
+1 for me.
The current system with the branches has frustrated me a couple of
times. This way of branching can be seen with multiple projects and
seems to be working there just fine.
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
[1] http://markmail.org/message/ucixhhdbz3ajyv2a
Regards,
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.
