cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: github organisation cloudstack
Date Fri, 18 Mar 2016 18:03:34 GMT
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 <wstevens@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 <runseb@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message