You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <da...@gmail.com> on 2016/03/15 23:07:17 UTC
github organisation cloudstack
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?
Will we let/ask Schuberg Philis to put cosmic in there?
Will be ask/let Will to run upr to it (so we don't depend on the
foundation)?
How will we sink it from/to apache or the apache github organisation?
Any other ideas/questions?
let's discuss or better,
--
Daan
Re: github organisation cloudstack
Posted by Erik Weber <te...@gmail.com>.
On Wed, Mar 16, 2016 at 8:46 PM, Will Stevens <ws...@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.
I'd say we tackle that problem once we have a working and bulletproof CI.
In the meantime we can either make dummy PRs or copy some from the ASF org
to run in the CI.
As long as we have concensus, I would imagine that we could ask
contributors to send PRs here instead when the time comes?
--
Erik
Re: github organisation cloudstack
Posted by Will Stevens <wi...@gmail.com>.
I mentioned it here since that was the thread that Sam and Chris were most
engaged in, so I wanted the people who were watching these other threads be
aware of that thread as we were getting good traction there.
On Mar 19, 2016 9:57 AM, "Daan Hoogland" <da...@gmail.com> wrote:
> Will,
>
> On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens <ws...@cloudops.com>
> wrote:
>
> > 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
>
> I liked my/this title of the thread better. The fork is not meant to be
> external. It is meant to be the canonical source to file change requests
> and - proposals against isn't it?
>
> of course this is only secondary to the fact that it was 'my' title ;)
>
>
>
> >
> >
> > Please come join the conversation in that thread...
> >
> please
>
>
> --
> Daan
>
Re: github organisation cloudstack
Posted by Will Stevens <wi...@gmail.com>.
I agree that your title better describes what we are trying to achieve.
On Mar 19, 2016 9:57 AM, "Daan Hoogland" <da...@gmail.com> wrote:
> Will,
>
> On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens <ws...@cloudops.com>
> wrote:
>
> > 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
>
> I liked my/this title of the thread better. The fork is not meant to be
> external. It is meant to be the canonical source to file change requests
> and - proposals against isn't it?
>
> of course this is only secondary to the fact that it was 'my' title ;)
>
>
>
> >
> >
> > Please come join the conversation in that thread...
> >
> please
>
>
> --
> Daan
>
Re: github organisation cloudstack
Posted by Daan Hoogland <da...@gmail.com>.
Will,
On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens <ws...@cloudops.com> wrote:
> 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
I liked my/this title of the thread better. The fork is not meant to be
external. It is meant to be the canonical source to file change requests
and - proposals against isn't it?
of course this is only secondary to the fact that it was 'my' title ;)
>
>
> Please come join the conversation in that thread...
>
please
--
Daan
Re: github organisation cloudstack
Posted by Will Stevens <ws...@cloudops.com>.
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 <ws...@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 <ru...@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 <ws...@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 <te...@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
>> >>
>>
>>
>
Re: github organisation cloudstack
Posted by Will Stevens <ws...@cloudops.com>.
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 <ru...@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 <ws...@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 <te...@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
> >>
>
>
Re: github organisation cloudstack
Posted by Sebastien Goasguen <ru...@gmail.com>.
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 <ws...@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 <te...@gmail.com> wrote:
>
>> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <da...@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
>>
Re: github organisation cloudstack
Posted by Will Stevens <ws...@cloudops.com>.
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 <te...@gmail.com> wrote:
> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <da...@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
>
Re: github organisation cloudstack
Posted by Erik Weber <te...@gmail.com>.
On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <da...@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
Re: github organisation cloudstack
Posted by Sebastien Goasguen <ru...@gmail.com>.
I am in favor of having a few volunteers start experimenting with it.
Especially with/for CI
I don’t think we have urgency to make any bold move right now.
One thing we could do for sure, is to move everything that’s in CloudStak-Extras to cloudstack org.
> On Mar 15, 2016, at 11:43 PM, Nux! <nu...@li.nux.ro> wrote:
>
> It seemed pretty obvious that being hold back by Apache's traditional infra was a big problem.
> I am not a developer, but even I have noticed the revolution github brought with it.
> I say we push it forward.. I am not exactly sure how this will affect our Apache status..
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> ----- Original Message -----
>> From: "Daan Hoogland" <da...@gmail.com>
>> To: "dev" <de...@cloudstack.apache.org>
>> Sent: Tuesday, 15 March, 2016 22:07:17
>> Subject: github organisation cloudstack
>
>> 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?
>> Will we let/ask Schuberg Philis to put cosmic in there?
>> Will be ask/let Will to run upr to it (so we don't depend on the
>> foundation)?
>> How will we sink it from/to apache or the apache github organisation?
>> Any other ideas/questions?
>>
>> let's discuss or better,
>> --
>> Daan
Re: github organisation cloudstack
Posted by Nux! <nu...@li.nux.ro>.
It seemed pretty obvious that being hold back by Apache's traditional infra was a big problem.
I am not a developer, but even I have noticed the revolution github brought with it.
I say we push it forward.. I am not exactly sure how this will affect our Apache status..
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
----- Original Message -----
> From: "Daan Hoogland" <da...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Sent: Tuesday, 15 March, 2016 22:07:17
> Subject: github organisation cloudstack
> 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?
> Will we let/ask Schuberg Philis to put cosmic in there?
> Will be ask/let Will to run upr to it (so we don't depend on the
> foundation)?
> How will we sink it from/to apache or the apache github organisation?
> Any other ideas/questions?
>
> let's discuss or better,
> --
> Daan