+1 for merges(no-ff) from stable to unstable.
There are pros and cons of ff and no-ff. I prefer no-ff.

-1 on frequent merges in RC stage.
IMO, we shouldn't cut a release a branch until we are reasonably sure that
we have a stable branch. Which would mean everyone working on the release.
once we cut the branch, we start working towards the next release and the
release focus is lost.
I also prefer a single merge after the release is voted. (The changes
should be minimal)

~Rajani


On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
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
> [ ] +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.
>

Reply via email to