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 <run...@gmail.com> wrote: > > 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 > > > >
