You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by sebgoa <ru...@gmail.com> on 2014/10/18 11:00:17 UTC
[PROPOSAL] Move to github PR only during moratorium on commit
After [1] I would like to officially bring up the following proposal.
[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.
----
This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
[Reasons]:
----
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.
----
Our development and release process is broken, we cannot continue like this, let's fix it.
[1] http://markmail.org/thread/xeliefp3oleq3g54
-sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Erik Weber <te...@gmail.com>.
On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
> Won’t this proposal make GitHub the canonical repository? I don’t see ASF
> infra being too happy with that.
>
>
Shouldn't have to, you can still merge/push to the ASF infra repository and
only the PR would live on github.
It's probably a tad more hassle for the one pushing the commit. I guess
Sebastien or Pierre-Luc can chime in with experiences from the doc repos.
--
Erik
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Pierre-Luc Dion <pd...@apache.org>.
Here is my experience with pull request on github for documentation: as
non comiter it is very easy for a one time pull request. But, because ACS
github repo is a mirror, next PR from the same fork branch almost never
worked because initial PR add a merge commit which is not in the fork
branch. I don't remember if 'git rebase' solved this issue. So found it
little annoying when not familiar with Git.
As comiter, I did approved and push PR's, because PR cannot be perform on
github, I did extract a patch, review and push to main repo. It worked but
its time consuming and add a merge commit. Maybe apply to PR as PR in git
would have worked, I've never tried it, I'm not a git guru.
Since PR is a GIT feature, could we use this PR proposal on the main repo
instead of github? unless part of the idea is to benefit from the github
website and tools?
Github is great but because it is currently a mirror of ACS repo, it might
add some complexity when applying PR. but seams to be more maintainable
then the current master branch madness and it also facilitate outsider
contributions.
So +1 for the PR idea, but could it be extend to the main repo, not just
github as Chiradeep pointed out?
Pierre-Luc
On Mon, Oct 20, 2014 at 5:22 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Oct 20, 2014, at 8:28 PM, Chiradeep Vittal <Ch...@citrix.com>
> wrote:
>
> > Thanks. Question for Sebastien then. The argument is that this new
> proposal will avoid problems such as
> > - broken builds. Presumably this is test failures (don’t recall a
> compile-time failure). How exactly would this be achieved WITHOUT a CI
> process?
>
> I am not arguing against a CI process. We currently have TravisCI for
> smoke test and it runs on every commit. It will also run on every PR. So at
> a minimum when doing a review we can check that smoke tests (and therefore
> build) pass before merging.
> We also have Jenkins and if we were to get in the habit of creating
> branches for every bug/hotfix they would automatically be tested via
> jenkins as well.
>
> My point being that a full fledged CI where we test all combination of
> hypervisor/storage/network is still way out until we seriously tackle it.
>
> This proposal would help us change our commit habits to help reduce
> release time by better reviewing and merging things.
>
> > - delayed releases. Not sure how this fixes it. Seems like it is just
> introducing a bottleneck for the sake of slowing things down?
>
> No, it's not for the sake of slowing things down. It will certainly be a
> bit of a pain at first, but the whole idea is to make releases on time and
> more easily.
>
> Currently we develop on master, since we branch releases off master, each
> new release is quite divergent from a the previous one, and we re-invest a
> lot of time from release to release to stabilize them. If we could base a
> release of a stable master, we could actually *construct* a release, by
> picking features that are ready and we would have greater confidence that
> bugs fixed during QA time (in our current process) would actually be in the
> next release.
>
> > - features merged without warning. Warnings are good. But what does one
> do with (let’s say a 3-day) warning? One must trust the developer or trust
> the developer and the CI system.
>
> I don't have a specific example, but we have seen features being merged
> without tests, uncomplete features being merged and we even have struggled
> to identified new features that are in a release.
>
> At a minimum, this would serve at publicising a features to the whole
> community.
>
> > The argument it seems is for a stable master vs a stable release
> branch. Is that the correct summary? Why not switch to that model on ACS
> git instead of GitHub?
>
> "stable" is a bit of a blinking word. What I mean when I use stable is
> that I would like to make sure that master is always in a releasable state,
> so that we avoid duplicating QA when we prep a release.
>
> Say we QA master and we get to a releasable (as in voted release) state,
> then when we start fixing bugs in the release branch we can cleanly merge
> those back in master and we have certainty that master will also be
> releasable. If we keep iterating like this, the next time we branch a
> release branch, we can merge the features selected for that release and we
> are done (ideally).
>
> Going through github PR gives us a basic review functionality, as well as
> basic smoke tests. Basically it will gate every commit (for a while), until
> we get in the habit of committing in the correct place. This is not about
> questioning committers code quality (while it will help quality by offering
> a clear review process), it is about changing habits to help with releasing
> on-time and with transparency on what is in a release.
>
>
>
> > From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> > Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> <de...@cloudstack.apache.org>>
> > Date: Monday, October 20, 2014 at 10:34 AM
> > To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> commit
> >
> > No Chiradeep, Pull of the request will still be on the local committer
> repo
> > and pushed to ASF infra (wip)
> >
> > On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <
> > Chiradeep.Vittal@citrix.com<ma...@citrix.com>> wrote:
> >
> > Won’t this proposal make GitHub the canonical repository? I don’t see ASF
> > infra being too happy with that.
> >
> > From: sebgoa <ru...@gmail.com><mailto:
> runseb@gmail.com>>
> > Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org
> ><ma...@cloudstack.apache.org>" <
> > dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
> dev@cloudstack.apache.org>>
> > Date: Saturday, October 18, 2014 at 2:00 AM
> > To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
> dev@cloudstack.apache.org>" <
> > dev@cloudstack.apache.org<ma...@cloudstack.apache.org><mailto:
> dev@cloudstack.apache.org>>
> > Subject: [PROPOSAL] Move to github PR only during moratorium on commit
> >
> > After [1] I would like to officially bring up the following proposal.
> >
> > [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.
> > ----
> >
> > This is drastic and I am sure some folks will not like it, but here is my
> > justification for such a measure:
> >
> > [Reasons]:
> > ----
> > 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.
> > ----
> >
> > Our development and release process is broken, we cannot continue like
> > this, let's fix it.
> >
> > [1] http://markmail.org/thread/xeliefp3oleq3g54
> >
> > -sebastien
> >
> >
> >
> >
> > --
> > Daan
> >
>
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by sebgoa <ru...@gmail.com>.
On Oct 20, 2014, at 8:28 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> Thanks. Question for Sebastien then. The argument is that this new proposal will avoid problems such as
> - broken builds. Presumably this is test failures (don’t recall a compile-time failure). How exactly would this be achieved WITHOUT a CI process?
I am not arguing against a CI process. We currently have TravisCI for smoke test and it runs on every commit. It will also run on every PR. So at a minimum when doing a review we can check that smoke tests (and therefore build) pass before merging.
We also have Jenkins and if we were to get in the habit of creating branches for every bug/hotfix they would automatically be tested via jenkins as well.
My point being that a full fledged CI where we test all combination of hypervisor/storage/network is still way out until we seriously tackle it.
This proposal would help us change our commit habits to help reduce release time by better reviewing and merging things.
> - delayed releases. Not sure how this fixes it. Seems like it is just introducing a bottleneck for the sake of slowing things down?
No, it's not for the sake of slowing things down. It will certainly be a bit of a pain at first, but the whole idea is to make releases on time and more easily.
Currently we develop on master, since we branch releases off master, each new release is quite divergent from a the previous one, and we re-invest a lot of time from release to release to stabilize them. If we could base a release of a stable master, we could actually *construct* a release, by picking features that are ready and we would have greater confidence that bugs fixed during QA time (in our current process) would actually be in the next release.
> - features merged without warning. Warnings are good. But what does one do with (let’s say a 3-day) warning? One must trust the developer or trust the developer and the CI system.
I don't have a specific example, but we have seen features being merged without tests, uncomplete features being merged and we even have struggled to identified new features that are in a release.
At a minimum, this would serve at publicising a features to the whole community.
> The argument it seems is for a stable master vs a stable release branch. Is that the correct summary? Why not switch to that model on ACS git instead of GitHub?
"stable" is a bit of a blinking word. What I mean when I use stable is that I would like to make sure that master is always in a releasable state, so that we avoid duplicating QA when we prep a release.
Say we QA master and we get to a releasable (as in voted release) state, then when we start fixing bugs in the release branch we can cleanly merge those back in master and we have certainty that master will also be releasable. If we keep iterating like this, the next time we branch a release branch, we can merge the features selected for that release and we are done (ideally).
Going through github PR gives us a basic review functionality, as well as basic smoke tests. Basically it will gate every commit (for a while), until we get in the habit of committing in the correct place. This is not about questioning committers code quality (while it will help quality by offering a clear review process), it is about changing habits to help with releasing on-time and with transparency on what is in a release.
> From: Daan Hoogland <da...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
> Date: Monday, October 20, 2014 at 10:34 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
> Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit
>
> No Chiradeep, Pull of the request will still be on the local committer repo
> and pushed to ASF infra (wip)
>
> On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <
> Chiradeep.Vittal@citrix.com<ma...@citrix.com>> wrote:
>
> Won’t this proposal make GitHub the canonical repository? I don’t see ASF
> infra being too happy with that.
>
> From: sebgoa <ru...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Saturday, October 18, 2014 at 2:00 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like
> this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
>
>
>
>
> --
> Daan
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Thanks. Question for Sebastien then. The argument is that this new proposal will avoid problems such as
- broken builds. Presumably this is test failures (don’t recall a compile-time failure). How exactly would this be achieved WITHOUT a CI process?
- delayed releases. Not sure how this fixes it. Seems like it is just introducing a bottleneck for the sake of slowing things down?
- features merged without warning. Warnings are good. But what does one do with (let’s say a 3-day) warning? One must trust the developer or trust the developer and the CI system.
The argument it seems is for a stable master vs a stable release branch. Is that the correct summary? Why not switch to that model on ACS git instead of GitHub?
From: Daan Hoogland <da...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Monday, October 20, 2014 at 10:34 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit
No Chiradeep, Pull of the request will still be on the local committer repo
and pushed to ASF infra (wip)
On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com<ma...@citrix.com>> wrote:
Won’t this proposal make GitHub the canonical repository? I don’t see ASF
infra being too happy with that.
From: sebgoa <ru...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
Date: Saturday, October 18, 2014 at 2:00 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
Subject: [PROPOSAL] Move to github PR only during moratorium on commit
After [1] I would like to officially bring up the following proposal.
[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.
----
This is drastic and I am sure some folks will not like it, but here is my
justification for such a measure:
[Reasons]:
----
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.
----
Our development and release process is broken, we cannot continue like
this, let's fix it.
[1] http://markmail.org/thread/xeliefp3oleq3g54
-sebastien
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
No Chiradeep, Pull of the request will still be on the local committer repo
and pushed to ASF infra (wip)
On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
> Won’t this proposal make GitHub the canonical repository? I don’t see ASF
> infra being too happy with that.
>
> From: sebgoa <ru...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Saturday, October 18, 2014 at 2:00 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like
> this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
>
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that.
From: sebgoa <ru...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Saturday, October 18, 2014 at 2:00 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Subject: [PROPOSAL] Move to github PR only during moratorium on commit
After [1] I would like to officially bring up the following proposal.
[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.
----
This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
[Reasons]:
----
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.
----
Our development and release process is broken, we cannot continue like this, let's fix it.
[1] http://markmail.org/thread/xeliefp3oleq3g54
-sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by sebgoa <ru...@gmail.com>.
On Oct 22, 2014, at 1:21 AM, David Nalley <da...@gnsa.us> wrote:
> Hi Sebastien:
>
> So I like the idea of:
>
> 1. Us putting up all inbound code for review.
> 2. Gating that code on a testing pass
> 3. Having someone else look at it before committing.
>
> I don't think that should mean that all code that works gets an
> immediate pass. I also don't think that we should have n RMs for
> branches. It doesn't scale, and it moves us from consensus to
> authoritarian. I am all for reverting things that break, but think
> that should be a community wide responsibility, not one or two
> policemen.
>
> I also think this is a huge shift in process. Right now we have 145
> open patches on ReviewBoard. We average scores of commits per day; so
> understand that this is a huge, gigantic shift in how we work. This
> requires a high level of commitment from everyone, and frankly it's
> likely to bury TravisCI.
>
> I also worry about the effect of this on our ability to timely ship
> 4.5. We have 14 Critical and blocker bugs for 4.5, and part of me
> worries that this is a distraction for 4.5 release efforts.
>
> Please don't take this as discounting your proposal or your concerns.
> I don't think that many folks disagrees in principle with the first 3
> points above. But timing, and implementation details may be an issue.
>
> --David
I respectfully disagree with you. I hear your concerns but I feel that we are at a stage where we need drastic measures.
I understand this may sound like an authoritarian proposal but this is how I see it, I don't like the way we develop cloudstack and I am not even a software engineer.
I am off for 2 weeks, and won't be able to check on this or defend this proposal.
-sebastien
>
> On Sat, Oct 18, 2014 at 5:00 AM, sebgoa <ru...@gmail.com> wrote:
>> After [1] I would like to officially bring up the following proposal.
>>
>> [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.
>> ----
>>
>> This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
>>
>> [Reasons]:
>> ----
>> 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.
>> ----
>>
>> Our development and release process is broken, we cannot continue like this, let's fix it.
>>
>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>
>> -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by David Nalley <da...@gnsa.us>.
Hi Sebastien:
So I like the idea of:
1. Us putting up all inbound code for review.
2. Gating that code on a testing pass
3. Having someone else look at it before committing.
I don't think that should mean that all code that works gets an
immediate pass. I also don't think that we should have n RMs for
branches. It doesn't scale, and it moves us from consensus to
authoritarian. I am all for reverting things that break, but think
that should be a community wide responsibility, not one or two
policemen.
I also think this is a huge shift in process. Right now we have 145
open patches on ReviewBoard. We average scores of commits per day; so
understand that this is a huge, gigantic shift in how we work. This
requires a high level of commitment from everyone, and frankly it's
likely to bury TravisCI.
I also worry about the effect of this on our ability to timely ship
4.5. We have 14 Critical and blocker bugs for 4.5, and part of me
worries that this is a distraction for 4.5 release efforts.
Please don't take this as discounting your proposal or your concerns.
I don't think that many folks disagrees in principle with the first 3
points above. But timing, and implementation details may be an issue.
--David
On Sat, Oct 18, 2014 at 5:00 AM, sebgoa <ru...@gmail.com> wrote:
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by sebgoa <ru...@gmail.com>.
On Oct 21, 2014, at 9:36 AM, Daan Hoogland <da...@gmail.com> wrote:
> Ok, no one says it so let me be the bad guy.
>
> <rant>
> Nothing will work unless the citrix department in california agrees. They
> have their in-house legacy proces to change and will not unless they can
> sell it easily upstream. So whether we make a grand uninfied proposal or
> take small steps doesn't matter, it must fit their internal political
> situation.
> This is very unhealthy. I am not saying that the objections coming from
> that group are unreasonable every time. Sometimes they were more then other
> times. I am even sure that they are working on improving as well but this
> is invisible to the rest of us. A mail every once in a while does not make
> this visible. The proces of improving the way we work is impaired by it.
> They to need to make small steps so we can see what is happening and where
> we are going. Even a grand proposal by Citrix California won't be accepted,
> because the change will be to big!
> </rant>
>
> <frustrated conclusion>
> I made some small steps in improving during the 4.4.1 release process.
> These were largely ignored or reverted in the current branch. unless the
> current state of 4.5 happens to be very good we are in for a repeat of
> recent history.
> </frustrated conclusion>
>
> You know where to find me,
> Daan
I will mostly +1 this
-sebastien
>
> On Tue, Oct 21, 2014 at 6:32 AM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Code reviews are great.
>>
>> However, we will need to change our behavior quite a bit if code is to make
>> it in within a reasonable amount of time as code reviews today often don't
>> get done in a timely fashion.
>>
>> In a volunteer community, it's hard to "assign" work (including code
>> reviews) to people (let alone expect it done on your schedule).
>>
>> This is, of course, different at most of our day jobs where managers are in
>> a position to make sure the community is responsive.
>>
>> On Monday, October 20, 2014, Rajani Karuturi <ra...@apache.org> wrote:
>>
>>> I like the way Stephen split it.
>>> Here is my vote.
>>> +1 on using github pull requests.
>>> +1 on compulsory code reviews and PRs even for committers and CI build
>> pass
>>> before merging.
>>> +1 on merges from 4.5 to master and no individual commits(or
>> cherry-picks)
>>> to the branches
>>> +0 on RM for master and commits gated by him. I agree with Stephen that
>>> code reviewer should be doing the push. But, I am ok with RM doing
>>> it(assuming we have a volunteer ;) ).
>>>
>>> +1 on any changes independently.
>>>
>>>
>>> ~Rajani
>>>
>>> On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner <
>> Stephen.Turner@citrix.com
>>> <javascript:;>>
>>> wrote:
>>>
>>>> As I just said in the other thread -- but to repeat it here in the
>>>> PROPOSAL thread --
>>>>
>>>> I am +1 on using github pull requests.
>>>>
>>>> I am +1 on all code changes being reviewed by a committer other than
>> the
>>>> author, as well as undergoing some automated CI testing, before the
>> pull
>>>> request is merged.
>>>>
>>>> I am +0 on only the master RM merging the pull request. I don't want
>> the
>>>> author to push the code, but I think the code reviewer could do this;
>> in
>>>> practice the RM will not be able to review everything again so is
>> likely
>>> to
>>>> rubber-stamp the results of the code review / automated testing. But I
>>>> could live with the master RM doing it.
>>>>
>>>> I am +1 on moving ahead with any of these parts individually, rather
>> than
>>>> waiting for everything to be in place before doing anything.
>>>>
>>>> --
>>>> Stephen Turner
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: sebgoa [mailto:runseb@gmail.com <javascript:;>]
>>>> Sent: 18 October 2014 10:00
>>>> To: dev@cloudstack.apache.org <javascript:;>
>>>> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>>>>
>>>> After [1] I would like to officially bring up the following proposal.
>>>>
>>>> [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.
>>>> ----
>>>>
>>>> This is drastic and I am sure some folks will not like it, but here is
>> my
>>>> justification for such a measure:
>>>>
>>>> [Reasons]:
>>>> ----
>>>> 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.
>>>> ----
>>>>
>>>> Our development and release process is broken, we cannot continue like
>>>> this, let's fix it.
>>>>
>>>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>>>
>>>> -sebastien
>>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>
>
>
> --
> Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
Ok, no one says it so let me be the bad guy.
<rant>
Nothing will work unless the citrix department in california agrees. They
have their in-house legacy proces to change and will not unless they can
sell it easily upstream. So whether we make a grand uninfied proposal or
take small steps doesn't matter, it must fit their internal political
situation.
This is very unhealthy. I am not saying that the objections coming from
that group are unreasonable every time. Sometimes they were more then other
times. I am even sure that they are working on improving as well but this
is invisible to the rest of us. A mail every once in a while does not make
this visible. The proces of improving the way we work is impaired by it.
They to need to make small steps so we can see what is happening and where
we are going. Even a grand proposal by Citrix California won't be accepted,
because the change will be to big!
</rant>
<frustrated conclusion>
I made some small steps in improving during the 4.4.1 release process.
These were largely ignored or reverted in the current branch. unless the
current state of 4.5 happens to be very good we are in for a repeat of
recent history.
</frustrated conclusion>
You know where to find me,
Daan
On Tue, Oct 21, 2014 at 6:32 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> Code reviews are great.
>
> However, we will need to change our behavior quite a bit if code is to make
> it in within a reasonable amount of time as code reviews today often don't
> get done in a timely fashion.
>
> In a volunteer community, it's hard to "assign" work (including code
> reviews) to people (let alone expect it done on your schedule).
>
> This is, of course, different at most of our day jobs where managers are in
> a position to make sure the community is responsive.
>
> On Monday, October 20, 2014, Rajani Karuturi <ra...@apache.org> wrote:
>
> > I like the way Stephen split it.
> > Here is my vote.
> > +1 on using github pull requests.
> > +1 on compulsory code reviews and PRs even for committers and CI build
> pass
> > before merging.
> > +1 on merges from 4.5 to master and no individual commits(or
> cherry-picks)
> > to the branches
> > +0 on RM for master and commits gated by him. I agree with Stephen that
> > code reviewer should be doing the push. But, I am ok with RM doing
> > it(assuming we have a volunteer ;) ).
> >
> > +1 on any changes independently.
> >
> >
> > ~Rajani
> >
> > On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner <
> Stephen.Turner@citrix.com
> > <javascript:;>>
> > wrote:
> >
> > > As I just said in the other thread -- but to repeat it here in the
> > > PROPOSAL thread --
> > >
> > > I am +1 on using github pull requests.
> > >
> > > I am +1 on all code changes being reviewed by a committer other than
> the
> > > author, as well as undergoing some automated CI testing, before the
> pull
> > > request is merged.
> > >
> > > I am +0 on only the master RM merging the pull request. I don't want
> the
> > > author to push the code, but I think the code reviewer could do this;
> in
> > > practice the RM will not be able to review everything again so is
> likely
> > to
> > > rubber-stamp the results of the code review / automated testing. But I
> > > could live with the master RM doing it.
> > >
> > > I am +1 on moving ahead with any of these parts individually, rather
> than
> > > waiting for everything to be in place before doing anything.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -----Original Message-----
> > > From: sebgoa [mailto:runseb@gmail.com <javascript:;>]
> > > Sent: 18 October 2014 10:00
> > > To: dev@cloudstack.apache.org <javascript:;>
> > > Subject: [PROPOSAL] Move to github PR only during moratorium on commit
> > >
> > > After [1] I would like to officially bring up the following proposal.
> > >
> > > [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.
> > > ----
> > >
> > > This is drastic and I am sure some folks will not like it, but here is
> my
> > > justification for such a measure:
> > >
> > > [Reasons]:
> > > ----
> > > 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.
> > > ----
> > >
> > > Our development and release process is broken, we cannot continue like
> > > this, let's fix it.
> > >
> > > [1] http://markmail.org/thread/xeliefp3oleq3g54
> > >
> > > -sebastien
> > >
> >
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by sebgoa <ru...@gmail.com>.
On Oct 21, 2014, at 6:32 AM, Mike Tutkowski <mi...@solidfire.com> wrote:
> Code reviews are great.
>
> However, we will need to change our behavior quite a bit if code is to make
> it in within a reasonable amount of time as code reviews today often don't
> get done in a timely fashion.
Just look at it as an incremental step forward. Reviews could just be a "ship it", like we see many times on RB.
The point is really to track the commits better and have the RMs (whatever many we have), to do the commits and construct the release branches.
This would be much better than the free for all we have right now and would redirect development to feature branches and bugfix branches until merged.
And fwiw, I do believe that RM is a full time job.
>
> In a volunteer community, it's hard to "assign" work (including code
> reviews) to people (let alone expect it done on your schedule).
>
> This is, of course, different at most of our day jobs where managers are in
> a position to make sure the community is responsive.
>
> On Monday, October 20, 2014, Rajani Karuturi <ra...@apache.org> wrote:
>
>> I like the way Stephen split it.
>> Here is my vote.
>> +1 on using github pull requests.
>> +1 on compulsory code reviews and PRs even for committers and CI build pass
>> before merging.
>> +1 on merges from 4.5 to master and no individual commits(or cherry-picks)
>> to the branches
>> +0 on RM for master and commits gated by him. I agree with Stephen that
>> code reviewer should be doing the push. But, I am ok with RM doing
>> it(assuming we have a volunteer ;) ).
>>
>> +1 on any changes independently.
>>
>>
>> ~Rajani
>>
>> On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner <Stephen.Turner@citrix.com
>> <javascript:;>>
>> wrote:
>>
>>> As I just said in the other thread -- but to repeat it here in the
>>> PROPOSAL thread --
>>>
>>> I am +1 on using github pull requests.
>>>
>>> I am +1 on all code changes being reviewed by a committer other than the
>>> author, as well as undergoing some automated CI testing, before the pull
>>> request is merged.
>>>
>>> I am +0 on only the master RM merging the pull request. I don't want the
>>> author to push the code, but I think the code reviewer could do this; in
>>> practice the RM will not be able to review everything again so is likely
>> to
>>> rubber-stamp the results of the code review / automated testing. But I
>>> could live with the master RM doing it.
>>>
>>> I am +1 on moving ahead with any of these parts individually, rather than
>>> waiting for everything to be in place before doing anything.
>>>
>>> --
>>> Stephen Turner
>>>
>>>
>>> -----Original Message-----
>>> From: sebgoa [mailto:runseb@gmail.com <javascript:;>]
>>> Sent: 18 October 2014 10:00
>>> To: dev@cloudstack.apache.org <javascript:;>
>>> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>>>
>>> After [1] I would like to officially bring up the following proposal.
>>>
>>> [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.
>>> ----
>>>
>>> This is drastic and I am sure some folks will not like it, but here is my
>>> justification for such a measure:
>>>
>>> [Reasons]:
>>> ----
>>> 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.
>>> ----
>>>
>>> Our development and release process is broken, we cannot continue like
>>> this, let's fix it.
>>>
>>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>>
>>> -sebastien
>>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Mike Tutkowski <mi...@solidfire.com>.
Code reviews are great.
However, we will need to change our behavior quite a bit if code is to make
it in within a reasonable amount of time as code reviews today often don't
get done in a timely fashion.
In a volunteer community, it's hard to "assign" work (including code
reviews) to people (let alone expect it done on your schedule).
This is, of course, different at most of our day jobs where managers are in
a position to make sure the community is responsive.
On Monday, October 20, 2014, Rajani Karuturi <ra...@apache.org> wrote:
> I like the way Stephen split it.
> Here is my vote.
> +1 on using github pull requests.
> +1 on compulsory code reviews and PRs even for committers and CI build pass
> before merging.
> +1 on merges from 4.5 to master and no individual commits(or cherry-picks)
> to the branches
> +0 on RM for master and commits gated by him. I agree with Stephen that
> code reviewer should be doing the push. But, I am ok with RM doing
> it(assuming we have a volunteer ;) ).
>
> +1 on any changes independently.
>
>
> ~Rajani
>
> On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner <Stephen.Turner@citrix.com
> <javascript:;>>
> wrote:
>
> > As I just said in the other thread -- but to repeat it here in the
> > PROPOSAL thread --
> >
> > I am +1 on using github pull requests.
> >
> > I am +1 on all code changes being reviewed by a committer other than the
> > author, as well as undergoing some automated CI testing, before the pull
> > request is merged.
> >
> > I am +0 on only the master RM merging the pull request. I don't want the
> > author to push the code, but I think the code reviewer could do this; in
> > practice the RM will not be able to review everything again so is likely
> to
> > rubber-stamp the results of the code review / automated testing. But I
> > could live with the master RM doing it.
> >
> > I am +1 on moving ahead with any of these parts individually, rather than
> > waiting for everything to be in place before doing anything.
> >
> > --
> > Stephen Turner
> >
> >
> > -----Original Message-----
> > From: sebgoa [mailto:runseb@gmail.com <javascript:;>]
> > Sent: 18 October 2014 10:00
> > To: dev@cloudstack.apache.org <javascript:;>
> > Subject: [PROPOSAL] Move to github PR only during moratorium on commit
> >
> > After [1] I would like to officially bring up the following proposal.
> >
> > [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.
> > ----
> >
> > This is drastic and I am sure some folks will not like it, but here is my
> > justification for such a measure:
> >
> > [Reasons]:
> > ----
> > 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.
> > ----
> >
> > Our development and release process is broken, we cannot continue like
> > this, let's fix it.
> >
> > [1] http://markmail.org/thread/xeliefp3oleq3g54
> >
> > -sebastien
> >
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
I like the way Stephen split it.
Here is my vote.
+1 on using github pull requests.
+1 on compulsory code reviews and PRs even for committers and CI build pass
before merging.
+1 on merges from 4.5 to master and no individual commits(or cherry-picks)
to the branches
+0 on RM for master and commits gated by him. I agree with Stephen that
code reviewer should be doing the push. But, I am ok with RM doing
it(assuming we have a volunteer ;) ).
+1 on any changes independently.
~Rajani
On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner <St...@citrix.com>
wrote:
> As I just said in the other thread -- but to repeat it here in the
> PROPOSAL thread --
>
> I am +1 on using github pull requests.
>
> I am +1 on all code changes being reviewed by a committer other than the
> author, as well as undergoing some automated CI testing, before the pull
> request is merged.
>
> I am +0 on only the master RM merging the pull request. I don't want the
> author to push the code, but I think the code reviewer could do this; in
> practice the RM will not be able to review everything again so is likely to
> rubber-stamp the results of the code review / automated testing. But I
> could live with the master RM doing it.
>
> I am +1 on moving ahead with any of these parts individually, rather than
> waiting for everything to be in place before doing anything.
>
> --
> Stephen Turner
>
>
> -----Original Message-----
> From: sebgoa [mailto:runseb@gmail.com]
> Sent: 18 October 2014 10:00
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like
> this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Ian Duffy <ia...@ianduffy.ie>.
I'm in complete agreement with Stephen on this one.
I would be considered the master RM could be overwhelmed with work.
Other than that +1.
On 20 October 2014 14:13, Daan Hoogland <da...@gmail.com> wrote:
> +1 and small changes should go through even if bigger goals glare on the
> horizon.
>
> On Mon, Oct 20, 2014 at 2:14 PM, sebgoa <ru...@gmail.com> wrote:
>
> >
> > On Oct 20, 2014, at 1:51 PM, Stephen Turner <St...@citrix.com>
> > wrote:
> >
> > > As I just said in the other thread -- but to repeat it here in the
> > PROPOSAL thread --
> > >
> > > I am +1 on using github pull requests.
> > >
> > > I am +1 on all code changes being reviewed by a committer other than
> the
> > author, as well as undergoing some automated CI testing, before the pull
> > request is merged.
> > >
> > > I am +0 on only the master RM merging the pull request. I don't want
> the
> > author to push the code, but I think the code reviewer could do this; in
> > practice the RM will not be able to review everything again so is likely
> to
> > rubber-stamp the results of the code review / automated testing. But I
> > could live with the master RM doing it.
> > >
> >
> > Understood, the idea is to go with this drastic change and as we adjust
> we
> > can relax a bit this constraint. The benefit is to start controlling what
> > will go in the next release before a release branch is even cut and get
> all
> > developers (committers or not) to start using feature branches
> > systematically.
> >
> > > I am +1 on moving ahead with any of these parts individually, rather
> > than waiting for everything to be in place before doing anything.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -----Original Message-----
> > > From: sebgoa [mailto:runseb@gmail.com]
> > > Sent: 18 October 2014 10:00
> > > To: dev@cloudstack.apache.org
> > > Subject: [PROPOSAL] Move to github PR only during moratorium on commit
> > >
> > > After [1] I would like to officially bring up the following proposal.
> > >
> > > [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.
> > > ----
> > >
> > > This is drastic and I am sure some folks will not like it, but here is
> > my justification for such a measure:
> > >
> > > [Reasons]:
> > > ----
> > > 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.
> > > ----
> > >
> > > Our development and release process is broken, we cannot continue like
> > this, let's fix it.
> > >
> > > [1] http://markmail.org/thread/xeliefp3oleq3g54
> > >
> > > -sebastien
> >
> >
>
>
> --
> Daan
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
+1 and small changes should go through even if bigger goals glare on the
horizon.
On Mon, Oct 20, 2014 at 2:14 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Oct 20, 2014, at 1:51 PM, Stephen Turner <St...@citrix.com>
> wrote:
>
> > As I just said in the other thread -- but to repeat it here in the
> PROPOSAL thread --
> >
> > I am +1 on using github pull requests.
> >
> > I am +1 on all code changes being reviewed by a committer other than the
> author, as well as undergoing some automated CI testing, before the pull
> request is merged.
> >
> > I am +0 on only the master RM merging the pull request. I don't want the
> author to push the code, but I think the code reviewer could do this; in
> practice the RM will not be able to review everything again so is likely to
> rubber-stamp the results of the code review / automated testing. But I
> could live with the master RM doing it.
> >
>
> Understood, the idea is to go with this drastic change and as we adjust we
> can relax a bit this constraint. The benefit is to start controlling what
> will go in the next release before a release branch is even cut and get all
> developers (committers or not) to start using feature branches
> systematically.
>
> > I am +1 on moving ahead with any of these parts individually, rather
> than waiting for everything to be in place before doing anything.
> >
> > --
> > Stephen Turner
> >
> >
> > -----Original Message-----
> > From: sebgoa [mailto:runseb@gmail.com]
> > Sent: 18 October 2014 10:00
> > To: dev@cloudstack.apache.org
> > Subject: [PROPOSAL] Move to github PR only during moratorium on commit
> >
> > After [1] I would like to officially bring up the following proposal.
> >
> > [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.
> > ----
> >
> > This is drastic and I am sure some folks will not like it, but here is
> my justification for such a measure:
> >
> > [Reasons]:
> > ----
> > 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.
> > ----
> >
> > Our development and release process is broken, we cannot continue like
> this, let's fix it.
> >
> > [1] http://markmail.org/thread/xeliefp3oleq3g54
> >
> > -sebastien
>
>
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by sebgoa <ru...@gmail.com>.
On Oct 20, 2014, at 1:51 PM, Stephen Turner <St...@citrix.com> wrote:
> As I just said in the other thread -- but to repeat it here in the PROPOSAL thread --
>
> I am +1 on using github pull requests.
>
> I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged.
>
> I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it.
>
Understood, the idea is to go with this drastic change and as we adjust we can relax a bit this constraint. The benefit is to start controlling what will go in the next release before a release branch is even cut and get all developers (committers or not) to start using feature branches systematically.
> I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything.
>
> --
> Stephen Turner
>
>
> -----Original Message-----
> From: sebgoa [mailto:runseb@gmail.com]
> Sent: 18 October 2014 10:00
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Move to github PR only during moratorium on commit
>
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
RE: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Stephen Turner <St...@citrix.com>.
As I just said in the other thread -- but to repeat it here in the PROPOSAL thread --
I am +1 on using github pull requests.
I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged.
I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it.
I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything.
--
Stephen Turner
-----Original Message-----
From: sebgoa [mailto:runseb@gmail.com]
Sent: 18 October 2014 10:00
To: dev@cloudstack.apache.org
Subject: [PROPOSAL] Move to github PR only during moratorium on commit
After [1] I would like to officially bring up the following proposal.
[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.
----
This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
[Reasons]:
----
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.
----
Our development and release process is broken, we cannot continue like this, let's fix it.
[1] http://markmail.org/thread/xeliefp3oleq3g54
-sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi,
> On 18-Oct-2014, at 2:30 pm, sebgoa <ru...@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
Much needed and Github is just more fun than RB any day. Merging gives us the benefit of reverting the merge by reverting on the merge commit which is useful to revert a merge that break some functionality and perhaps not the build.
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.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Erik Weber <te...@gmail.com>.
On Sat, Oct 18, 2014 at 11:00 AM, sebgoa <ru...@gmail.com> wrote:
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> [Reasons]:
> ----
> 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.
> ----
>
I'm +1 to any change that could improve quality, and submitting to github
as non-committer is a magnitude faster/easier than RB.
--
Erik
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Wido den Hollander <wi...@widodh.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/18/2014 11:00 AM, sebgoa wrote:
> After [1] I would like to officially bring up the following
> proposal.
>
> [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. ----
>
> This is drastic and I am sure some folks will not like it, but here
> is my justification for such a measure:
>
I fully understand the reasoning and I agree that this is the best way
forward.
Code quality is much more needed then new features. Revert without
warning is also just fine.
It will take some time to adjust, but this would be a great thing to do.
Wido
> [Reasons]: ---- 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. ----
>
> Our development and release process is broken, we cannot continue
> like this, let's fix it.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUROXIAAoJEAGbWC3bPspCifwP/1NtM7L61p8YI/W4qn9LH+fs
oo5PeLY61IitdDGJoT7DTfiJhCgM4HWYHKyZOUkZLm53wUKbrUuzSVZ6ZIfrlss6
erWIXCHrk2VPzaBX3nyOBzaEdrnLYTlMdJgxHVd5IUq+HBtf3GPQDUHu3EnsNKk4
BP+3fJg5hfIF4jkevXlGebcdsT9CWQIz3Z656Dr1tknYUBlTyM+wBOsp3BhAEWG0
VTC9Gt/YfOo3P3xWEBUZ40GRhd4bM9OaHhiDqN/vz4wKyz7X2//oShudVSTZsrg9
Hm2CYt9W1/TjLEAk87VBvtNyY4U9OaZTnQBK/T+N7uu7E8whFmqffDDWYiSmBt+J
UDsYQfn/U/aKqgyMasXRWTF8CxZHRM8YyZzwbrMhVYUPdlsnhUdmzksG7zKwcNjp
rpXcS3LkXW6xp0sYp6MWdUp7EVhpDE7q06HiWDONrrKRdyKTxO9P+tWWUJJdVee/
zwb617SIFyDYK9DBKSDSGIdAFE81rl+PBTqPJe2wotJ5KKuRbcVWaqFqvWqmuLxs
XiMiB3CduBbLecmyEqa0szQqv9OXRHeNGvrjEM29L7kYSb6Rua05jmTwFXEj+1Ob
IxF9wOB/licwfCOE8VSNz8xbiptbtloKhT4OFyliFW/RAuBwQlznus8A9xGVgYz1
gCnEIljSR6Tle3F9kvU7
=MHeW
-----END PGP SIGNATURE-----
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Srikanteswararao Talluri <sr...@citrix.com>.
I could get easily merge all my changes in 4.5 to master yesterday. Merge
to master is no more a problem. Thanks to Rajani for fixing merge issues
with master.
I think, at least, from now we can keep the master mergable.
For others who are interested in knowing what I¹ve just tried:
1. <push your changes to 4.5>
2. Git checkout master
3. Git pull
4. Git merge 4.5
Thanks,
~Talluri
On 30/10/14 3:51 pm, "Srikanteswararao Talluri"
<sr...@citrix.com> wrote:
>Hey Folks,
>
>After all these discussions, What is the direction to commit the code to
>master and 4.5? I have some commits on 4.5 which I would like to have them
>on master too. How to go about it?
>
>Thanks,
>~Talluri
>
>On 23/10/14 11:47 am, "Animesh Chaturvedi" <an...@citrix.com>
>wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: sebgoa [mailto:runseb@gmail.com]
>>> Sent: Saturday, October 18, 2014 2:00 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: [PROPOSAL] Move to github PR only during moratorium on
>>> commit
>>>
>>> After [1] I would like to officially bring up the following proposal.
>>>
>>> [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.
>>> ----
>>>
>>> This is drastic and I am sure some folks will not like it, but here is
>>>my
>>> justification for such a measure:
>>>
>>> [Reasons]:
>>> ----
>>> 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).
>>
>>
>>[Animesh] Sebastian you have brought up a good point dependency on QA
>>team from Citrix is an issue for the project. This was raised in the past
>>as well and Alex's proposal [1] few months back using CI was in my
>>opinion is the optimal solution. Why? Because CloudStack is a huge
>>project and one single person cannot have the full knowledge to safely
>>review all the code and certainly cannot scale, which CI and automation
>>can address
>>
>>Keeping master stable is something no one would argue against and my
>>point would match the original proposal from Alex. May be we can have a
>>staging branch for master and then merging the commit only after they
>>have passed CI into master. The proposal got derailed and delayed because
>>as called out at that time community does not want to work with a process
>>that has a dependency on infrastructure that is not controlled by
>>community. David and I are working to get the hardware from Citrix into
>>ACS infra.
>>
>>The approach for fixing issues in release branch first and master later
>>is not practical as we may miss out commits not made into master and
>>future release regressing without the fixes. Also as the release goes
>>into hardening cycle there will be a number of fixes which will not be
>>allowed in release branch but need to be fixes for future, they should
>>all go in master. Master is the catch all default branch and in my
>>opinion should get fixes first.
>>
>>[1] http://markmail.org/thread/xoyjw2sduenlytwm
>>>
>>> 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.
>>>
>>[Animesh] Completely Agreed
>>> 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.
>>>
>>[Animesh] I have already expressed my opinion in favor of CI
>>
>>> 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.
>>> ----
>>>
>>> Our development and release process is broken, we cannot continue like
>>> this, let's fix it.
>>[Animesh] I followed up the release process as established by Chip for
>>4.2 and 4.3 release for which I was the RM and frankly I did not feel it
>>that way other than the pain of multiple RCs. Folks may not like it but I
>>am entitled to my opinion and I do feel part of the issues for 4.4 were
>>self- inflicted because of pre mature code freeze and too early cherry
>>picking.
>>>
>>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>>
>>> -sebastien
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
I share your frustration Rajani, I made some steps which I feel are
turned back now. I am giving up and really not feeling this is worth
my effort anymore.
People don't take the effort to commit on a branch. gating commits is
and will not solve unwillingness. It will slow us down at committing
bugs and force us to make more elaborate bugs at best.
merge forward is easy to implement *if we want it*. wanting is is a
must have prequisite.
On Wed, Nov 5, 2014 at 10:24 AM, Rajani Karuturi <ra...@apache.org> wrote:
> These problems existed for 4.4 and the same continued to 4.5. Despite
> discussing lot of things, we didnt act on anything and we are continuing
> the same to 4.6
>
> There is no plan whatsoever to address any of those issues.
>
> ~Rajani
>
> On Wed, Nov 5, 2014 at 2:33 AM, David Nalley <da...@gnsa.us> wrote:
>
>> On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi <ra...@apache.org>
>> wrote:
>> > that means, we postponed the git problems to 4.6. :(
>> >
>> > It feels like as a community we are running away from making any changes
>> to
>> > the way we interact with git. We seem to discuss it a lot but, never act
>> on
>> > it.
>>
>> I don't think we are running away from them. I certainly hope not.
>> There are competing demands (like everything)
>> 1. We want to ship 4.5
>> 2. We want to have new features being developed
>> 3. We want to fix quality issues
>> 4. We want to fix process issues
>>
>> Each of those is at odds with each other. They are also hard problems,
>> and frankly most of them are as much a cultural problem as a technical
>> problem.
>>
>> >
>> > What I don't understand is, are we saying the way we use git is right? or
>> > are we just shying away from any change?
>> >
>>
>> We are saying that #2 forced us to fork 4.5 into a different branch.
>> Master and 4.5 are now diverging, and we want to #1 to happen. 1 & 2
>> are incompatible on the same branch, but their competition is keeping
>> 3 and 4 at bay.
>>
>> That doesn't mean we shouldn't change, but you can only pull in so
>> many directions without things coming apart.
>>
>> --David
>>
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
These problems existed for 4.4 and the same continued to 4.5. Despite
discussing lot of things, we didnt act on anything and we are continuing
the same to 4.6
There is no plan whatsoever to address any of those issues.
~Rajani
On Wed, Nov 5, 2014 at 2:33 AM, David Nalley <da...@gnsa.us> wrote:
> On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi <ra...@apache.org>
> wrote:
> > that means, we postponed the git problems to 4.6. :(
> >
> > It feels like as a community we are running away from making any changes
> to
> > the way we interact with git. We seem to discuss it a lot but, never act
> on
> > it.
>
> I don't think we are running away from them. I certainly hope not.
> There are competing demands (like everything)
> 1. We want to ship 4.5
> 2. We want to have new features being developed
> 3. We want to fix quality issues
> 4. We want to fix process issues
>
> Each of those is at odds with each other. They are also hard problems,
> and frankly most of them are as much a cultural problem as a technical
> problem.
>
> >
> > What I don't understand is, are we saying the way we use git is right? or
> > are we just shying away from any change?
> >
>
> We are saying that #2 forced us to fork 4.5 into a different branch.
> Master and 4.5 are now diverging, and we want to #1 to happen. 1 & 2
> are incompatible on the same branch, but their competition is keeping
> 3 and 4 at bay.
>
> That doesn't mean we shouldn't change, but you can only pull in so
> many directions without things coming apart.
>
> --David
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by David Nalley <da...@gnsa.us>.
On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi <ra...@apache.org> wrote:
> that means, we postponed the git problems to 4.6. :(
>
> It feels like as a community we are running away from making any changes to
> the way we interact with git. We seem to discuss it a lot but, never act on
> it.
I don't think we are running away from them. I certainly hope not.
There are competing demands (like everything)
1. We want to ship 4.5
2. We want to have new features being developed
3. We want to fix quality issues
4. We want to fix process issues
Each of those is at odds with each other. They are also hard problems,
and frankly most of them are as much a cultural problem as a technical
problem.
>
> What I don't understand is, are we saying the way we use git is right? or
> are we just shying away from any change?
>
We are saying that #2 forced us to fork 4.5 into a different branch.
Master and 4.5 are now diverging, and we want to #1 to happen. 1 & 2
are incompatible on the same branch, but their competition is keeping
3 and 4 at bay.
That doesn't mean we shouldn't change, but you can only pull in so
many directions without things coming apart.
--David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
as Travis is happy and some of my tests went fine, I pushed the merge.
~Rajani
On Wed, Nov 5, 2014 at 2:55 PM, Rajani Karuturi <ra...@apache.org> wrote:
> Travis is happy with the merge. Can I push this?
>
> ~Rajani
>
> On Wed, Nov 5, 2014 at 12:38 PM, Rajani Karuturi <ra...@apache.org>
> wrote:
>
>> I did merge -s ours and somehow didnt see any issue. (
>> https://github.com/apache/cloudstack/pull/36)
>> will wait for the Travis report (
>> https://travis-ci.org/apache/cloudstack/builds/40033174)
>>
>> I havent used -X before. But, from the documentation I understood it as,
>> the merge strategy will be applied only when doing a conflict resolution.
>> If my understanding is right, we shouldnt be using -X.
>>
>> ~Rajani
>>
>> On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>
>>> Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help.
>>>
>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>> Op 3 nov. 2014 05:40 schreef "Rajani Karuturi" <ra...@apache.org>:
>>>
>>> > that means, we postponed the git problems to 4.6. :(
>>> >
>>> > It feels like as a community we are running away from making any
>>> changes to
>>> > the way we interact with git. We seem to discuss it a lot but, never
>>> act on
>>> > it.
>>> >
>>> > What I don't understand is, are we saying the way we use git is right?
>>> or
>>> > are we just shying away from any change?
>>> >
>>> >
>>> > ~Rajani
>>> >
>>> > PS: We could still do a blank merge(-s ours) from 4.5 to master and
>>> > continue.
>>> >
>>> > On Sat, Nov 1, 2014 at 12:06 AM, David Nalley <da...@gnsa.us> wrote:
>>> >
>>> > > On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <rajani@apache.org
>>> >
>>> > > wrote:
>>> > > > Can we atleast follow the merge part of it? ie) commit to 4.5 and
>>> then
>>> > > > merge 4.5 to master?
>>> > > >
>>> > > > merging wont be easy unless everybody agrees and does merge for
>>> their
>>> > > > commits.
>>> > > >
>>> > >
>>> > > It won't work; master and 4.5 have both diverged, even if it's very
>>> > > small at this point.
>>> > > Daan and I both seemed to come to this conclusion last week:
>>> > >
>>> > > http://markmail.org/message/sumgmlo4avgjquym
>>> > > http://markmail.org/message/wazq4lz47v22mynz
>>> > >
>>> > > --David
>>> > >
>>> >
>>>
>>
>>
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
Travis is happy with the merge. Can I push this?
~Rajani
On Wed, Nov 5, 2014 at 12:38 PM, Rajani Karuturi <ra...@apache.org> wrote:
> I did merge -s ours and somehow didnt see any issue. (
> https://github.com/apache/cloudstack/pull/36)
> will wait for the Travis report (
> https://travis-ci.org/apache/cloudstack/builds/40033174)
>
> I havent used -X before. But, from the documentation I understood it as,
> the merge strategy will be applied only when doing a conflict resolution.
> If my understanding is right, we shouldnt be using -X.
>
> ~Rajani
>
> On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
>> Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help.
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 3 nov. 2014 05:40 schreef "Rajani Karuturi" <ra...@apache.org>:
>>
>> > that means, we postponed the git problems to 4.6. :(
>> >
>> > It feels like as a community we are running away from making any
>> changes to
>> > the way we interact with git. We seem to discuss it a lot but, never
>> act on
>> > it.
>> >
>> > What I don't understand is, are we saying the way we use git is right?
>> or
>> > are we just shying away from any change?
>> >
>> >
>> > ~Rajani
>> >
>> > PS: We could still do a blank merge(-s ours) from 4.5 to master and
>> > continue.
>> >
>> > On Sat, Nov 1, 2014 at 12:06 AM, David Nalley <da...@gnsa.us> wrote:
>> >
>> > > On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <ra...@apache.org>
>> > > wrote:
>> > > > Can we atleast follow the merge part of it? ie) commit to 4.5 and
>> then
>> > > > merge 4.5 to master?
>> > > >
>> > > > merging wont be easy unless everybody agrees and does merge for
>> their
>> > > > commits.
>> > > >
>> > >
>> > > It won't work; master and 4.5 have both diverged, even if it's very
>> > > small at this point.
>> > > Daan and I both seemed to come to this conclusion last week:
>> > >
>> > > http://markmail.org/message/sumgmlo4avgjquym
>> > > http://markmail.org/message/wazq4lz47v22mynz
>> > >
>> > > --David
>> > >
>> >
>>
>
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
I did merge -s ours and somehow didnt see any issue. (
https://github.com/apache/cloudstack/pull/36)
will wait for the Travis report (
https://travis-ci.org/apache/cloudstack/builds/40033174)
I havent used -X before. But, from the documentation I understood it as,
the merge strategy will be applied only when doing a conflict resolution.
If my understanding is right, we shouldnt be using -X.
~Rajani
On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland <da...@gmail.com>
wrote:
> Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help.
>
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 3 nov. 2014 05:40 schreef "Rajani Karuturi" <ra...@apache.org>:
>
> > that means, we postponed the git problems to 4.6. :(
> >
> > It feels like as a community we are running away from making any changes
> to
> > the way we interact with git. We seem to discuss it a lot but, never act
> on
> > it.
> >
> > What I don't understand is, are we saying the way we use git is right? or
> > are we just shying away from any change?
> >
> >
> > ~Rajani
> >
> > PS: We could still do a blank merge(-s ours) from 4.5 to master and
> > continue.
> >
> > On Sat, Nov 1, 2014 at 12:06 AM, David Nalley <da...@gnsa.us> wrote:
> >
> > > On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <ra...@apache.org>
> > > wrote:
> > > > Can we atleast follow the merge part of it? ie) commit to 4.5 and
> then
> > > > merge 4.5 to master?
> > > >
> > > > merging wont be easy unless everybody agrees and does merge for their
> > > > commits.
> > > >
> > >
> > > It won't work; master and 4.5 have both diverged, even if it's very
> > > small at this point.
> > > Daan and I both seemed to come to this conclusion last week:
> > >
> > > http://markmail.org/message/sumgmlo4avgjquym
> > > http://markmail.org/message/wazq4lz47v22mynz
> > >
> > > --David
> > >
> >
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help.
mobile dev with bilingual spelling checker used (read at your own risk)
Op 3 nov. 2014 05:40 schreef "Rajani Karuturi" <ra...@apache.org>:
> that means, we postponed the git problems to 4.6. :(
>
> It feels like as a community we are running away from making any changes to
> the way we interact with git. We seem to discuss it a lot but, never act on
> it.
>
> What I don't understand is, are we saying the way we use git is right? or
> are we just shying away from any change?
>
>
> ~Rajani
>
> PS: We could still do a blank merge(-s ours) from 4.5 to master and
> continue.
>
> On Sat, Nov 1, 2014 at 12:06 AM, David Nalley <da...@gnsa.us> wrote:
>
> > On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <ra...@apache.org>
> > wrote:
> > > Can we atleast follow the merge part of it? ie) commit to 4.5 and then
> > > merge 4.5 to master?
> > >
> > > merging wont be easy unless everybody agrees and does merge for their
> > > commits.
> > >
> >
> > It won't work; master and 4.5 have both diverged, even if it's very
> > small at this point.
> > Daan and I both seemed to come to this conclusion last week:
> >
> > http://markmail.org/message/sumgmlo4avgjquym
> > http://markmail.org/message/wazq4lz47v22mynz
> >
> > --David
> >
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
that means, we postponed the git problems to 4.6. :(
It feels like as a community we are running away from making any changes to
the way we interact with git. We seem to discuss it a lot but, never act on
it.
What I don't understand is, are we saying the way we use git is right? or
are we just shying away from any change?
~Rajani
PS: We could still do a blank merge(-s ours) from 4.5 to master and
continue.
On Sat, Nov 1, 2014 at 12:06 AM, David Nalley <da...@gnsa.us> wrote:
> On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <ra...@apache.org>
> wrote:
> > Can we atleast follow the merge part of it? ie) commit to 4.5 and then
> > merge 4.5 to master?
> >
> > merging wont be easy unless everybody agrees and does merge for their
> > commits.
> >
>
> It won't work; master and 4.5 have both diverged, even if it's very
> small at this point.
> Daan and I both seemed to come to this conclusion last week:
>
> http://markmail.org/message/sumgmlo4avgjquym
> http://markmail.org/message/wazq4lz47v22mynz
>
> --David
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi <ra...@apache.org> wrote:
> Can we atleast follow the merge part of it? ie) commit to 4.5 and then
> merge 4.5 to master?
>
> merging wont be easy unless everybody agrees and does merge for their
> commits.
>
It won't work; master and 4.5 have both diverged, even if it's very
small at this point.
Daan and I both seemed to come to this conclusion last week:
http://markmail.org/message/sumgmlo4avgjquym
http://markmail.org/message/wazq4lz47v22mynz
--David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rajani Karuturi <ra...@apache.org>.
Can we atleast follow the merge part of it? ie) commit to 4.5 and then
merge 4.5 to master?
merging wont be easy unless everybody agrees and does merge for their
commits.
~Rajani
On Thu, Oct 30, 2014 at 8:44 PM, David Nalley <da...@gnsa.us> wrote:
> Commit to 4.5 and master please.
>
> --David
>
> On Thu, Oct 30, 2014 at 6:21 AM, Srikanteswararao Talluri
> <sr...@citrix.com> wrote:
> > Hey Folks,
> >
> > After all these discussions, What is the direction to commit the code to
> > master and 4.5? I have some commits on 4.5 which I would like to have
> them
> > on master too. How to go about it?
> >
> > Thanks,
> > ~Talluri
> >
> > On 23/10/14 11:47 am, "Animesh Chaturvedi" <
> animesh.chaturvedi@citrix.com>
> > wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: sebgoa [mailto:runseb@gmail.com]
> >>> Sent: Saturday, October 18, 2014 2:00 AM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: [PROPOSAL] Move to github PR only during moratorium on
> >>> commit
> >>>
> >>> After [1] I would like to officially bring up the following proposal.
> >>>
> >>> [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.
> >>> ----
> >>>
> >>> This is drastic and I am sure some folks will not like it, but here is
> >>>my
> >>> justification for such a measure:
> >>>
> >>> [Reasons]:
> >>> ----
> >>> 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).
> >>
> >>
> >>[Animesh] Sebastian you have brought up a good point dependency on QA
> >>team from Citrix is an issue for the project. This was raised in the past
> >>as well and Alex's proposal [1] few months back using CI was in my
> >>opinion is the optimal solution. Why? Because CloudStack is a huge
> >>project and one single person cannot have the full knowledge to safely
> >>review all the code and certainly cannot scale, which CI and automation
> >>can address
> >>
> >>Keeping master stable is something no one would argue against and my
> >>point would match the original proposal from Alex. May be we can have a
> >>staging branch for master and then merging the commit only after they
> >>have passed CI into master. The proposal got derailed and delayed because
> >>as called out at that time community does not want to work with a process
> >>that has a dependency on infrastructure that is not controlled by
> >>community. David and I are working to get the hardware from Citrix into
> >>ACS infra.
> >>
> >>The approach for fixing issues in release branch first and master later
> >>is not practical as we may miss out commits not made into master and
> >>future release regressing without the fixes. Also as the release goes
> >>into hardening cycle there will be a number of fixes which will not be
> >>allowed in release branch but need to be fixes for future, they should
> >>all go in master. Master is the catch all default branch and in my
> >>opinion should get fixes first.
> >>
> >>[1] http://markmail.org/thread/xoyjw2sduenlytwm
> >>>
> >>> 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.
> >>>
> >>[Animesh] Completely Agreed
> >>> 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.
> >>>
> >>[Animesh] I have already expressed my opinion in favor of CI
> >>
> >>> 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.
> >>> ----
> >>>
> >>> Our development and release process is broken, we cannot continue like
> >>> this, let's fix it.
> >>[Animesh] I followed up the release process as established by Chip for
> >>4.2 and 4.3 release for which I was the RM and frankly I did not feel it
> >>that way other than the pain of multiple RCs. Folks may not like it but I
> >>am entitled to my opinion and I do feel part of the issues for 4.4 were
> >>self- inflicted because of pre mature code freeze and too early cherry
> >>picking.
> >>>
> >>> [1] http://markmail.org/thread/xeliefp3oleq3g54
> >>>
> >>> -sebastien
> >
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by David Nalley <da...@gnsa.us>.
Commit to 4.5 and master please.
--David
On Thu, Oct 30, 2014 at 6:21 AM, Srikanteswararao Talluri
<sr...@citrix.com> wrote:
> Hey Folks,
>
> After all these discussions, What is the direction to commit the code to
> master and 4.5? I have some commits on 4.5 which I would like to have them
> on master too. How to go about it?
>
> Thanks,
> ~Talluri
>
> On 23/10/14 11:47 am, "Animesh Chaturvedi" <an...@citrix.com>
> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: sebgoa [mailto:runseb@gmail.com]
>>> Sent: Saturday, October 18, 2014 2:00 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: [PROPOSAL] Move to github PR only during moratorium on
>>> commit
>>>
>>> After [1] I would like to officially bring up the following proposal.
>>>
>>> [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.
>>> ----
>>>
>>> This is drastic and I am sure some folks will not like it, but here is
>>>my
>>> justification for such a measure:
>>>
>>> [Reasons]:
>>> ----
>>> 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).
>>
>>
>>[Animesh] Sebastian you have brought up a good point dependency on QA
>>team from Citrix is an issue for the project. This was raised in the past
>>as well and Alex's proposal [1] few months back using CI was in my
>>opinion is the optimal solution. Why? Because CloudStack is a huge
>>project and one single person cannot have the full knowledge to safely
>>review all the code and certainly cannot scale, which CI and automation
>>can address
>>
>>Keeping master stable is something no one would argue against and my
>>point would match the original proposal from Alex. May be we can have a
>>staging branch for master and then merging the commit only after they
>>have passed CI into master. The proposal got derailed and delayed because
>>as called out at that time community does not want to work with a process
>>that has a dependency on infrastructure that is not controlled by
>>community. David and I are working to get the hardware from Citrix into
>>ACS infra.
>>
>>The approach for fixing issues in release branch first and master later
>>is not practical as we may miss out commits not made into master and
>>future release regressing without the fixes. Also as the release goes
>>into hardening cycle there will be a number of fixes which will not be
>>allowed in release branch but need to be fixes for future, they should
>>all go in master. Master is the catch all default branch and in my
>>opinion should get fixes first.
>>
>>[1] http://markmail.org/thread/xoyjw2sduenlytwm
>>>
>>> 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.
>>>
>>[Animesh] Completely Agreed
>>> 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.
>>>
>>[Animesh] I have already expressed my opinion in favor of CI
>>
>>> 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.
>>> ----
>>>
>>> Our development and release process is broken, we cannot continue like
>>> this, let's fix it.
>>[Animesh] I followed up the release process as established by Chip for
>>4.2 and 4.3 release for which I was the RM and frankly I did not feel it
>>that way other than the pain of multiple RCs. Folks may not like it but I
>>am entitled to my opinion and I do feel part of the issues for 4.4 were
>>self- inflicted because of pre mature code freeze and too early cherry
>>picking.
>>>
>>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>>
>>> -sebastien
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Srikanteswararao Talluri <sr...@citrix.com>.
Hey Folks,
After all these discussions, What is the direction to commit the code to
master and 4.5? I have some commits on 4.5 which I would like to have them
on master too. How to go about it?
Thanks,
~Talluri
On 23/10/14 11:47 am, "Animesh Chaturvedi" <an...@citrix.com>
wrote:
>
>
>> -----Original Message-----
>> From: sebgoa [mailto:runseb@gmail.com]
>> Sent: Saturday, October 18, 2014 2:00 AM
>> To: dev@cloudstack.apache.org
>> Subject: [PROPOSAL] Move to github PR only during moratorium on
>> commit
>>
>> After [1] I would like to officially bring up the following proposal.
>>
>> [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.
>> ----
>>
>> This is drastic and I am sure some folks will not like it, but here is
>>my
>> justification for such a measure:
>>
>> [Reasons]:
>> ----
>> 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).
>
>
>[Animesh] Sebastian you have brought up a good point dependency on QA
>team from Citrix is an issue for the project. This was raised in the past
>as well and Alex's proposal [1] few months back using CI was in my
>opinion is the optimal solution. Why? Because CloudStack is a huge
>project and one single person cannot have the full knowledge to safely
>review all the code and certainly cannot scale, which CI and automation
>can address
>
>Keeping master stable is something no one would argue against and my
>point would match the original proposal from Alex. May be we can have a
>staging branch for master and then merging the commit only after they
>have passed CI into master. The proposal got derailed and delayed because
>as called out at that time community does not want to work with a process
>that has a dependency on infrastructure that is not controlled by
>community. David and I are working to get the hardware from Citrix into
>ACS infra.
>
>The approach for fixing issues in release branch first and master later
>is not practical as we may miss out commits not made into master and
>future release regressing without the fixes. Also as the release goes
>into hardening cycle there will be a number of fixes which will not be
>allowed in release branch but need to be fixes for future, they should
>all go in master. Master is the catch all default branch and in my
>opinion should get fixes first.
>
>[1] http://markmail.org/thread/xoyjw2sduenlytwm
>>
>> 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.
>>
>[Animesh] Completely Agreed
>> 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.
>>
>[Animesh] I have already expressed my opinion in favor of CI
>
>> 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.
>> ----
>>
>> Our development and release process is broken, we cannot continue like
>> this, let's fix it.
>[Animesh] I followed up the release process as established by Chip for
>4.2 and 4.3 release for which I was the RM and frankly I did not feel it
>that way other than the pain of multiple RCs. Folks may not like it but I
>am entitled to my opinion and I do feel part of the issues for 4.4 were
>self- inflicted because of pre mature code freeze and too early cherry
>picking.
>>
>> [1] http://markmail.org/thread/xeliefp3oleq3g54
>>
>> -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
On Fri, Oct 24, 2014 at 1:30 AM, Animesh Chaturvedi
<an...@citrix.com> wrote:
>> I sttrongly disagree with Animesh here and think Rohit is overlooking a
>> simple fact. At the moment the branches are for 'stabalizing'.
>> Fixing on master first is in direct contradiction with that.
>>
>> We have not been stabalizing 4.4. it contains bug that have during the
>> release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
>> have been allowed to happen.
> [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion
>
I abandoned that approach as cherry-picking started to give
complicated conflicts that I could not resolve. Also one particular
conflict, the one in the db upgrade script, kept coming back. This has
cost me a lot of time for work that was not there to begin with. Hence
my big aversion of the forward branches.
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Mike Tutkowski <mi...@solidfire.com>.
Yeah, Daan, the approach you describe sounds like a reasonable substitute
for what I have in that diagram.
My main concern was CI running before the code was checked into the "real"
branch from the staging branch.
On Fri, Oct 24, 2014 at 1:12 AM, Daan Hoogland <da...@gmail.com>
wrote:
> Mike, Why have everybody work on the same branch. people can work on
> their own branch and when they are done they can rebase on the tip see
> ci success and then merge. The problem with forward branches is
> abandoned work or work that for some reason shouldn't go in 'this'
> release. it will remain there.
>
> On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
> > Are we talking about something like what I drew up here?:
> >
> > http://i.imgur.com/UgPtJGY.png
> >
> > In this scheme, the -forward branches are the ones you can directly
> commit
> > to while their peers without the -forward are the ones that code gets
> > merged to from its corresponding -forward branch.
> >
> > CI is performed on the -forward branches before any merging takes place.
> >
> > The "merge recorded" concept I put in the diagram refers to the situation
> > where you have a commit on a branch like 4.5, but you do NOT want it to
> > move forward to master.
> >
> > I don't know if Git has such a concept, but SVN calls this kind of a
> > "merge" merge recording. Merge recording essentially means you do not
> want
> > those changes brought forward to the specified branch (not now and not
> with
> > future merges other people or yourself may do).
> >
> >
> >
> > On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi <
> > animesh.chaturvedi@citrix.com> wrote:
> >
> >>
> >>
> >> > -----Original Message-----
> >> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> >> > Sent: Thursday, October 23, 2014 1:31 AM
> >> > To: dev
> >> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> >> > commit
> >> >
> >> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
> >> > <ro...@shapeblue.com> wrote:
> >> > > Hi,
> >> > >
> >> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
> >> > <an...@citrix.com> wrote:
> >> > ...
> >> > >> The approach for fixing issues in release branch first and master
> >> later is
> >> > not practical as we may miss out commits not made into master and
> future
> >> > release regressing without the fixes.
> >> > >
> >> > > By the same logic, if we fix by default on master only, the release
> >> branch
> >> > may miss out commits.
> >> >
> >> > I sttrongly disagree with Animesh here and think Rohit is overlooking
> a
> >> > simple fact. At the moment the branches are for 'stabalizing'.
> >> > Fixing on master first is in direct contradiction with that.
> >> >
> >> > We have not been stabalizing 4.4. it contains bug that have during the
> >> > release periods for 4.4.0 and 4.4.1 been fixed on master. That
> shouldn't
> >> > have been allowed to happen.
> >> [Animesh] Clearly we have disagreement. To avoid the issue that you
> >> mention David had created forward branch for 4.2 and I found it useful
> and
> >> continued with that approach in 4.3. With forward branch which are
> really
> >> staging it was a simple merge of forward back to release branch. The
> other
> >> approach of merging release branch into master work as well but in my
> >> opinion keeping master as the default branch (with protection of course
> )
> >> is simpler to understand and creates less confusion
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*™*
>
>
>
> --
> Daan
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:30 schreef "David Nalley" <da...@gnsa.us>:
>
> On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <da...@gmail.com>
wrote:
> > Mike, Why have everybody work on the same branch. people can work on
> > their own branch and when they are done they can rebase on the tip see
> > ci success and then merge. The problem with forward branches is
> > abandoned work or work that for some reason shouldn't go in 'this'
> > release. it will remain there.
> >
>
> CI really needs to happen before the merge occurs, IMO.
Yes, that is exactly what i am saying
Backing out
> merges, in my experience, is incredibly painful. And typically this
> means that someone else is going to have to clean up the mess after
> someone merges.
and this is also what is wrong with the forward branches. It happened there
as well.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
At the moment it must be called 'hotfix/*' or 'bugfix/*'. we should
add 'feature/*' to that.
On Fri, Oct 24, 2014 at 11:11 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> Cool...so, it sounds like any branch we create in the repo will
> automatically have CI run against it post each commit.
>
> How do you know when CI has completed and what the results are?
>
> At that point, you could treat your own branch (as Daan says) as the
> "forward" branch. Once CI has been successful, you can merge your code to,
> say, 4.5 (or the RM can).
>
> We then need a protocol for when we merge to 4.5 from our own branch, but
> don't want to have those changes in master.
>
> If we do want those changes, of course we can just merge from 4.5 to master.
>
> On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
>> We do run ci on branches!
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" <
>> mike.tutkowski@solidfire.com
>> >:
>>
>> > Right, we just need to make sure CI comes into play before the merge.
>> >
>> > Hence my earlier reply to what Daan mention:
>> >
>> > "My main concern was CI running before the code was checked into the
>> "real"
>> > branch from the staging branch."
>> >
>> > On Fri, Oct 24, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
>> >
>> > > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <
>> daan.hoogland@gmail.com>
>> > > wrote:
>> > > > Mike, Why have everybody work on the same branch. people can work on
>> > > > their own branch and when they are done they can rebase on the tip
>> see
>> > > > ci success and then merge. The problem with forward branches is
>> > > > abandoned work or work that for some reason shouldn't go in 'this'
>> > > > release. it will remain there.
>> > > >
>> > >
>> > > CI really needs to happen before the merge occurs, IMO. Backing out
>> > > merges, in my experience, is incredibly painful. And typically this
>> > > means that someone else is going to have to clean up the mess after
>> > > someone merges.
>> > >
>> >
>> >
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkowski@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud
>> > <http://solidfire.com/solution/overview/?video=play>*™*
>> >
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Mike Tutkowski <mi...@solidfire.com>.
Cool...so, it sounds like any branch we create in the repo will
automatically have CI run against it post each commit.
How do you know when CI has completed and what the results are?
At that point, you could treat your own branch (as Daan says) as the
"forward" branch. Once CI has been successful, you can merge your code to,
say, 4.5 (or the RM can).
We then need a protocol for when we merge to 4.5 from our own branch, but
don't want to have those changes in master.
If we do want those changes, of course we can just merge from 4.5 to master.
On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland <da...@gmail.com>
wrote:
> We do run ci on branches!
>
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" <
> mike.tutkowski@solidfire.com
> >:
>
> > Right, we just need to make sure CI comes into play before the merge.
> >
> > Hence my earlier reply to what Daan mention:
> >
> > "My main concern was CI running before the code was checked into the
> "real"
> > branch from the staging branch."
> >
> > On Fri, Oct 24, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
> >
> > > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <
> daan.hoogland@gmail.com>
> > > wrote:
> > > > Mike, Why have everybody work on the same branch. people can work on
> > > > their own branch and when they are done they can rebase on the tip
> see
> > > > ci success and then merge. The problem with forward branches is
> > > > abandoned work or work that for some reason shouldn't go in 'this'
> > > > release. it will remain there.
> > > >
> > >
> > > CI really needs to happen before the merge occurs, IMO. Backing out
> > > merges, in my experience, is incredibly painful. And typically this
> > > means that someone else is going to have to clean up the mess after
> > > someone merges.
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*™*
> >
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
We do run ci on branches!
mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" <mike.tutkowski@solidfire.com
>:
> Right, we just need to make sure CI comes into play before the merge.
>
> Hence my earlier reply to what Daan mention:
>
> "My main concern was CI running before the code was checked into the "real"
> branch from the staging branch."
>
> On Fri, Oct 24, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
>
> > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <da...@gmail.com>
> > wrote:
> > > Mike, Why have everybody work on the same branch. people can work on
> > > their own branch and when they are done they can rebase on the tip see
> > > ci success and then merge. The problem with forward branches is
> > > abandoned work or work that for some reason shouldn't go in 'this'
> > > release. it will remain there.
> > >
> >
> > CI really needs to happen before the merge occurs, IMO. Backing out
> > merges, in my experience, is incredibly painful. And typically this
> > means that someone else is going to have to clean up the mess after
> > someone merges.
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Mike Tutkowski <mi...@solidfire.com>.
Right, we just need to make sure CI comes into play before the merge.
Hence my earlier reply to what Daan mention:
"My main concern was CI running before the code was checked into the "real"
branch from the staging branch."
On Fri, Oct 24, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
> On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> > Mike, Why have everybody work on the same branch. people can work on
> > their own branch and when they are done they can rebase on the tip see
> > ci success and then merge. The problem with forward branches is
> > abandoned work or work that for some reason shouldn't go in 'this'
> > release. it will remain there.
> >
>
> CI really needs to happen before the merge occurs, IMO. Backing out
> merges, in my experience, is incredibly painful. And typically this
> means that someone else is going to have to clean up the mess after
> someone merges.
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by David Nalley <da...@gnsa.us>.
On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <da...@gmail.com> wrote:
> Mike, Why have everybody work on the same branch. people can work on
> their own branch and when they are done they can rebase on the tip see
> ci success and then merge. The problem with forward branches is
> abandoned work or work that for some reason shouldn't go in 'this'
> release. it will remain there.
>
CI really needs to happen before the merge occurs, IMO. Backing out
merges, in my experience, is incredibly painful. And typically this
means that someone else is going to have to clean up the mess after
someone merges.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
Mike, Why have everybody work on the same branch. people can work on
their own branch and when they are done they can rebase on the tip see
ci success and then merge. The problem with forward branches is
abandoned work or work that for some reason shouldn't go in 'this'
release. it will remain there.
On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> Are we talking about something like what I drew up here?:
>
> http://i.imgur.com/UgPtJGY.png
>
> In this scheme, the -forward branches are the ones you can directly commit
> to while their peers without the -forward are the ones that code gets
> merged to from its corresponding -forward branch.
>
> CI is performed on the -forward branches before any merging takes place.
>
> The "merge recorded" concept I put in the diagram refers to the situation
> where you have a commit on a branch like 4.5, but you do NOT want it to
> move forward to master.
>
> I don't know if Git has such a concept, but SVN calls this kind of a
> "merge" merge recording. Merge recording essentially means you do not want
> those changes brought forward to the specified branch (not now and not with
> future merges other people or yourself may do).
>
>
>
> On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi <
> animesh.chaturvedi@citrix.com> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
>> > Sent: Thursday, October 23, 2014 1:31 AM
>> > To: dev
>> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
>> > commit
>> >
>> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
>> > <ro...@shapeblue.com> wrote:
>> > > Hi,
>> > >
>> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
>> > <an...@citrix.com> wrote:
>> > ...
>> > >> The approach for fixing issues in release branch first and master
>> later is
>> > not practical as we may miss out commits not made into master and future
>> > release regressing without the fixes.
>> > >
>> > > By the same logic, if we fix by default on master only, the release
>> branch
>> > may miss out commits.
>> >
>> > I sttrongly disagree with Animesh here and think Rohit is overlooking a
>> > simple fact. At the moment the branches are for 'stabalizing'.
>> > Fixing on master first is in direct contradiction with that.
>> >
>> > We have not been stabalizing 4.4. it contains bug that have during the
>> > release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
>> > have been allowed to happen.
>> [Animesh] Clearly we have disagreement. To avoid the issue that you
>> mention David had created forward branch for 4.2 and I found it useful and
>> continued with that approach in 4.3. With forward branch which are really
>> staging it was a simple merge of forward back to release branch. The other
>> approach of merging release branch into master work as well but in my
>> opinion keeping master as the default branch (with protection of course )
>> is simpler to understand and creates less confusion
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
--
Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Mike Tutkowski <mi...@solidfire.com>.
Are we talking about something like what I drew up here?:
http://i.imgur.com/UgPtJGY.png
In this scheme, the -forward branches are the ones you can directly commit
to while their peers without the -forward are the ones that code gets
merged to from its corresponding -forward branch.
CI is performed on the -forward branches before any merging takes place.
The "merge recorded" concept I put in the diagram refers to the situation
where you have a commit on a branch like 4.5, but you do NOT want it to
move forward to master.
I don't know if Git has such a concept, but SVN calls this kind of a
"merge" merge recording. Merge recording essentially means you do not want
those changes brought forward to the specified branch (not now and not with
future merges other people or yourself may do).
On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi <
animesh.chaturvedi@citrix.com> wrote:
>
>
> > -----Original Message-----
> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> > Sent: Thursday, October 23, 2014 1:31 AM
> > To: dev
> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> > commit
> >
> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
> > <ro...@shapeblue.com> wrote:
> > > Hi,
> > >
> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
> > <an...@citrix.com> wrote:
> > ...
> > >> The approach for fixing issues in release branch first and master
> later is
> > not practical as we may miss out commits not made into master and future
> > release regressing without the fixes.
> > >
> > > By the same logic, if we fix by default on master only, the release
> branch
> > may miss out commits.
> >
> > I sttrongly disagree with Animesh here and think Rohit is overlooking a
> > simple fact. At the moment the branches are for 'stabalizing'.
> > Fixing on master first is in direct contradiction with that.
> >
> > We have not been stabalizing 4.4. it contains bug that have during the
> > release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
> > have been allowed to happen.
> [Animesh] Clearly we have disagreement. To avoid the issue that you
> mention David had created forward branch for 4.2 and I found it useful and
> continued with that approach in 4.3. With forward branch which are really
> staging it was a simple merge of forward back to release branch. The other
> approach of merging release branch into master work as well but in my
> opinion keeping master as the default branch (with protection of course )
> is simpler to understand and creates less confusion
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
RE: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Thursday, October 23, 2014 1:31 AM
> To: dev
> Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> commit
>
> On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
> <ro...@shapeblue.com> wrote:
> > Hi,
> >
> >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
> <an...@citrix.com> wrote:
> ...
> >> The approach for fixing issues in release branch first and master later is
> not practical as we may miss out commits not made into master and future
> release regressing without the fixes.
> >
> > By the same logic, if we fix by default on master only, the release branch
> may miss out commits.
>
> I sttrongly disagree with Animesh here and think Rohit is overlooking a
> simple fact. At the moment the branches are for 'stabalizing'.
> Fixing on master first is in direct contradiction with that.
>
> We have not been stabalizing 4.4. it contains bug that have during the
> release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
> have been allowed to happen.
[Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Daan Hoogland <da...@gmail.com>.
On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
>> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi <an...@citrix.com> wrote:
...
>> The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes.
>
> By the same logic, if we fix by default on master only, the release branch may miss out commits.
I sttrongly disagree with Animesh here and think Rohit is overlooking
a simple fact. At the moment the branches are for 'stabalizing'.
Fixing on master first is in direct contradiction with that.
We have not been stabalizing 4.4. it contains bug that have during the
release periods for 4.4.0 and 4.4.1 been fixed on master. That
shouldn't have been allowed to happen.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: Thursday, October 23, 2014 1:22 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> commit
>
> Hi,
>
> > On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
> <an...@citrix.com> wrote:
> >
> > [Animesh] Sebastian you have brought up a good point dependency on
> QA team from Citrix is an issue for the project. This was raised in the past as
> well and Alex's proposal [1] few months back using CI was in my opinion is
> the optimal solution. Why? Because CloudStack is a huge project and one
> single person cannot have the full knowledge to safely review all the code
> and certainly cannot scale, which CI and automation can address
> >
> > Keeping master stable is something no one would argue against and my
> point would match the original proposal from Alex. May be we can have a
> staging branch for master and then merging the commit only after they
> have passed CI into master. The proposal got derailed and delayed because
> as called out at that time community does not want to work with a process
> that has a dependency on infrastructure that is not controlled by
> community. David and I are working to get the hardware from Citrix into
> ACS infra.
>
> Agree. Animesh has good point to share here.
>
> > The approach for fixing issues in release branch first and master later is
> not practical as we may miss out commits not made into master and future
> release regressing without the fixes.
>
> By the same logic, if we fix by default on master only, the release branch
> may miss out commits.
>
> At any given time, the release branch is hopefully more stable than master
> (since it’s getting bugfixes/hardening as Animesh shared). So, by merging
> release branch on master we get all those hardened changes back to master.
> If we fix things on release branch and keep merging the release branch on
> master, we fix the issue both on release branch and master branch.
>
> The only issue I see is code divergence between release branch and master
> branch as time passes.
>
[Animesh] Yes that is correct and that's why we had the forward branches in 4.2 and 4.3 so that commits go into forward branches (really staging) an master and it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and created less confusion
> > Also as the release goes into hardening cycle there will be a number of
> fixes which will not be allowed in release branch but need to be fixes for
> future, they should all go in master. Master is the catch all default branch
> and in my opinion should get fixes first.
>
> Agree, any fix that should not be done on release branch should go in to
> master.
>
> 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.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi,
> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi <an...@citrix.com> wrote:
>
> [Animesh] Sebastian you have brought up a good point dependency on QA team from Citrix is an issue for the project. This was raised in the past as well and Alex's proposal [1] few months back using CI was in my opinion is the optimal solution. Why? Because CloudStack is a huge project and one single person cannot have the full knowledge to safely review all the code and certainly cannot scale, which CI and automation can address
>
> Keeping master stable is something no one would argue against and my point would match the original proposal from Alex. May be we can have a staging branch for master and then merging the commit only after they have passed CI into master. The proposal got derailed and delayed because as called out at that time community does not want to work with a process that has a dependency on infrastructure that is not controlled by community. David and I are working to get the hardware from Citrix into ACS infra.
Agree. Animesh has good point to share here.
> The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes.
By the same logic, if we fix by default on master only, the release branch may miss out commits.
At any given time, the release branch is hopefully more stable than master (since it’s getting bugfixes/hardening as Animesh shared). So, by merging release branch on master we get all those hardened changes back to master. If we fix things on release branch and keep merging the release branch on master, we fix the issue both on release branch and master branch.
The only issue I see is code divergence between release branch and master branch as time passes.
> Also as the release goes into hardening cycle there will be a number of fixes which will not be allowed in release branch but need to be fixes for future, they should all go in master. Master is the catch all default branch and in my opinion should get fixes first.
Agree, any fix that should not be done on release branch should go in to master.
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.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: sebgoa [mailto:runseb@gmail.com]
> Sent: Saturday, October 18, 2014 2:00 AM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Move to github PR only during moratorium on
> commit
>
> After [1] I would like to officially bring up the following proposal.
>
> [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.
> ----
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> [Reasons]:
> ----
> 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).
[Animesh] Sebastian you have brought up a good point dependency on QA team from Citrix is an issue for the project. This was raised in the past as well and Alex's proposal [1] few months back using CI was in my opinion is the optimal solution. Why? Because CloudStack is a huge project and one single person cannot have the full knowledge to safely review all the code and certainly cannot scale, which CI and automation can address
Keeping master stable is something no one would argue against and my point would match the original proposal from Alex. May be we can have a staging branch for master and then merging the commit only after they have passed CI into master. The proposal got derailed and delayed because as called out at that time community does not want to work with a process that has a dependency on infrastructure that is not controlled by community. David and I are working to get the hardware from Citrix into ACS infra.
The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes. Also as the release goes into hardening cycle there will be a number of fixes which will not be allowed in release branch but need to be fixes for future, they should all go in master. Master is the catch all default branch and in my opinion should get fixes first.
[1] http://markmail.org/thread/xoyjw2sduenlytwm
>
> 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.
>
[Animesh] Completely Agreed
> 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.
>
[Animesh] I have already expressed my opinion in favor of CI
> 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.
> ----
>
> Our development and release process is broken, we cannot continue like
> this, let's fix it.
[Animesh] I followed up the release process as established by Chip for 4.2 and 4.3 release for which I was the RM and frankly I did not feel it that way other than the pain of multiple RCs. Folks may not like it but I am entitled to my opinion and I do feel part of the issues for 4.4 were self- inflicted because of pre mature code freeze and too early cherry picking.
>
> [1] http://markmail.org/thread/xeliefp3oleq3g54
>
> -sebastien