cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: github organisation cloudstack
Date Wed, 16 Mar 2016 19:55:32 GMT
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 <wstevens@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 <terbolous@gmail.com> wrote:
> 
>> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <daan.hoogland@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
>> 


Mime
View raw message