On Oct 20, 2014, at 8:28 PM, Chiradeep Vittal <chiradeep.vit...@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.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> > Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Date: Monday, October 20, 2014 at 10:34 AM > To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@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.vit...@citrix.com<mailto:chiradeep.vit...@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 > <run...@gmail.com<mailto:run...@gmail.com><mailto:run...@gmail.com>> > Reply-To: > "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>" > < > dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>> > Date: Saturday, October 18, 2014 at 2:00 AM > To: > "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>" > < > dev@cloudstack.apache.org<mailto:dev@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 >
