cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <raj...@apache.org>
Subject Re: merging versus cherry-picking
Date Thu, 16 Oct 2014 11:22:17 GMT
+1 on merging(and the proposal).

Unlike the belief that merging adds to dev time it actually makes life
easier to track a commit (after all, it has the same number of commands and
the same conflicts as cherry-pick :) )

We should also define merge strategy for LTS(4.3 and 4.4) branches.

~Rajani

On Thu, Oct 16, 2014 at 4:27 PM, Rohit Yadav <rohit.yadav@shapeblue.com>
wrote:

> Hi,
>
> On 16-Oct-2014, at 3:32 pm, sebgoa <runseb@gmail.com> wrote:
> > Proposal:
> > ----
> > All commits come through github PR, *even* for committers. We declare a
> moratorium period (agreed suspension of activity) during which direct
> commit to master is forbidden.
> > Only the master RM is allowed to merge PR in master (we define a master
> RM). If direct commit to master is done, master RM reverts without warning.
> Same for 4.5 and 4.4. branches.
> > ——
>
> +1
>
> We get the free TravisCI smoke checks and personally I find it more
> pleasant to view the diff, review on PR.
>
> > This is drastic and I am sure some folks will not like it, but here is
> my justification for such a measure:
> >
> > Our commit and release processes have so far been based on the idea that
> development happens on master and that a release branch is cut from master
> (unstable development branch). Then a different set of community members
> harden the release branch, QA and bring it to GA level. During that time
> development keeps on going in master.
> >
> > This is an OK process if we have the luxury of having a QA team and can
> cope with split personality of being developers and release managers.
> >
> > My point of view is that as a community we cannot afford such a split
> brain organization and our experience overt the last year proves my point
> (delayed release date, broken builds, features merged without warning…)
> >
> > We can avoid this by cutting a release branch from a stable one (from
> the start), then as you (Daan) have mentioned several times, fix bugs in
> the release branch and merge them back in the stable source of the release
> (be it master).
> >
> > Feature development need to be done outside master, period. Not only for
> non-committers but also for committers. And merge request need to be
> called. This will help review and avoid surprises.
> >
> > New git workflow were proposed and shutdown, mostly calling for better
> CI to solve quality issues. CI will not solve our quality issues alone. We
> need to better police ourselves.
> >
> > To avoid long discussions, I propose this simple but drastic measure. We
> move all our commits to github PR until 4.5 is out, this stands for
> committers and non-committers, direct commits (especially to master) would
> be reverted immediately.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message