Please be advised this conversation is continuing in a thread titled: Re: External fork of Cloudstack
Mailing list link: http://markmail.org/message/53ct2mma4x4jm6s2?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Re:+External+fork+of+Cloudstack Please come join the conversation in that thread... *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Wed, Mar 16, 2016 at 3:59 PM, Will Stevens <wstev...@cloudops.com> wrote: > The copying existing PRs would be for the purpose of running CI against it > in the context of being able to automate what happens next given the > result. > > I am going to be putting time into fixing marvin tests and also merging in > any fixes to marvin to try to get the CI runs as bulletproof as possible. > I agree this is the first step towards being able to move forward with > being able to automate anything. > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > On Wed, Mar 16, 2016 at 3:55 PM, Sebastien Goasguen <run...@gmail.com> > wrote: > >> Will, >> >> I think you are putting the carriage before the horse, sort of speak. >> >> I would suggest you make a dummy PR to cloudstack/cloudstack (just one, >> let’s not talk about migration or anything like that). >> >> then you can use this as a playground to see how you could improve our CI… >> >> The main idea being that we have control of this fork and can test the >> hell out of it and github integration capability. >> >> for instance, I can create auto-builds of Docker images now, something I >> can’t do with apache/cloudstack… >> >> I think it is way too early to worry/think about moving existing PR there. >> >> -sebastien >> >> > On Mar 16, 2016, at 8:46 PM, Will Stevens <wstev...@cloudops.com> >> wrote: >> > >> > If we use this I think it's main purpose should be to facilitate CI and >> > integration testing of the apache/cloudstack repo. >> > >> > The first hurdle in using this repo for CI work is the fact that none of >> > the open PRs from apache/cloudstack are available in the >> > cloudstack/cloudstack repo. If we are only using it for CI, that is >> not a >> > major problem because we can copy the PRs we care about from the >> > apache/cloudstack to the cloudstack/cloudstack repo programmatically. I >> > have already built a POC script and have successfully been able to copy >> a >> > pull request from one repository to a different fork of the same repo. >> > >> > Some things to note when doing this (which probably won't be an issue >> if we >> > only use it for CI): >> > - The PR number in cloudstack/cloudstack will not reflect the PR number >> > from apache/cloudstack. The apache/cloudstack PR number, author, etc >> could >> > be added to the body of the PR so we can easily navigate back to the >> > apache/cloudstack PR if we want to. >> > - The new PR in cloudstack/cloudstack will be owned by the person who >> runs >> > the copy pull request tool because it is their access token that is >> used to >> > create the new pull request. Again, if this is only used for CI, thats >> not >> > a major problem as we can reference the original author in the issue >> body >> > for the PR when we copy it. >> > - None of the comments will be copied over with the PR when we copy it. >> > This again, probably is not a deal breaker if we are only using it for >> CI. >> > We could potentially loop through the original PR comments and add them >> to >> > the copy, but I am not sure that is worth it. Again, they would all be >> > owned by the person who runs the tool, but we could again put the >> author in >> > the body. >> > >> > With this in mind, here are some of my ideas. >> > >> > We start by manually picking "mergeable" PRs that have at least 2 LGTM >> > votes and copying them to the cloudstack/cloudstack repo. We then use >> the >> > hooks in Github to automatically runCI against that PR in the >> > cloudstack/cloudstack repo. If the CI passes, then the code is >> > automatically merged into master and the official Apache repo is >> updated. >> > If it fails, the PR in cloudstack/cloudstack is updated with the status >> of >> > the CI run and the details. A comment is then pushed to the >> > apache/cloudstack PR referencing the cloudstack/cloudstack PR and the CI >> > status for that PR. >> > >> > There are obviously many other potential ways to do something similar, >> but >> > these are some of my original thoughts. We could also have it so that >> the >> > master is not automatically merged into the official master after the >> PR is >> > merged. We could also have a nightly CI run against master and if that >> > passes, then and only then is the master pushed to the official apache >> > master. >> > >> > Anyway, let the discussions continue. >> > >> > BTW, apache has taken notice that we have created the cloudstack org: >> > https://github.com/apache/cloudstack/pull/1442 >> > >> > *Will STEVENS* >> > Lead Developer >> > >> > *CloudOps* *| *Cloud Solutions Experts >> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 >> > w cloudops.com *|* tw @CloudOps_ >> > >> > On Wed, Mar 16, 2016 at 4:13 AM, Erik Weber <terbol...@gmail.com> >> wrote: >> > >> >> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland < >> daan.hoogl...@gmail.com> >> >> wrote: >> >> >> >>> devs, >> >>> >> >>> There is a github organisation called cloudstack, to which we have >> more >> >>> control then to the apache/cloudstack repo on github. We need to >> decide >> >> as >> >>> community what to do with it. >> >>> >> >>> What are we going to do in this new organisation? >> >>> >> >> >> >> How about we test out different ways of improving our CI/other >> automation >> >> tasks, without the 'pressure' we have with the official repos? >> >> I.e. there is no pressure to get things merged, just test things out. >> >> >> >> >> >>> Will we let/ask Schuberg Philis to put cosmic in there? >> >>> >> >> >> >> No offence, but why would we do that? Cosmic != CloudStack. They >> already >> >> have what looks like a healthy github organization. >> >> If they want to help improve the CloudStack organization then fine, but >> >> lets not mix Cosmic into this. >> >> >> >> >> >>> Will be ask/let Will to run upr to it (so we don't depend on the >> >>> foundation)? >> >>> >> >> >> >> I don't see why not, let Will, SB, SBP, Accelerite (I have no clue how >> to >> >> spell it right yet), or whoever wants to, do automated testing on it. >> >> We need to figure out how we should grant access in a systematic way, >> but >> >> as Will explained in a different thread -- the permissions needed are >> >> non-intrusive and imho we should be generous handing them out to >> whoever >> >> wants/needs, and revert that grant if necessary >> >> >> >> >> >>> How will we sink it from/to apache or the apache github organisation? >> >>> >> >> >> >> I guess we still need to commit things to git-wip.a.o to keep doing >> commits >> >> the apache way, that would keep the ASF github fork in sync. >> >> >> >> -- >> >> Erik >> >> >> >> >
