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 >
