cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)
Date Fri, 18 Mar 2016 07:40:08 GMT
Top posting because keeping track is going to be hard.

Remi and I have talked several times with David about GitHub access and so far the answer
has been no.

There are several issues in my understanding:

- apache on github is one single org, so if you get some write permission in the org then
you could potentially harm other projects. that means that ASF needs to figure out how to
use github teams to map our projects inside a single org (follow me…). They appear to be
working on it, but no ETA on when this will happen.

- location of the canonical repo. This in large a legal issue. If CloudStack were sued at
some point, can we prove without doubt who made the commit. Until now, ASF has the canonical
repo on its own hardware which means all sorts of logs including push logs. Some folks at
the ASF think that with a project on github they would not get the same level of guaranteed
provenance. ( I have tried to argue about it, some folks don’t think it is an issue, but
others do).

The bottom line for me:

-We are the ASF, the board is there for guidance but we, the communities and the ASF members
need to tell the board what we need/want.

-I want github, I am hearing a lot of you too.

-We informed the board several times, David has known for a while that we want this. Other
projects want it too (even though I don’t know which one).

-cloudstack/cloudstack is just an experiment for us, like the board is experimenting with
a Whimsy project that none of us are part of. So let’s work on our CI in cloudstack/cloudstack
(not talking about abandoning apache/cloudstack) and when the board comes around to do something
we will be ready.


> On Mar 18, 2016, at 4:37 AM, Will Stevens <> wrote:
> I may be thinking too far outside the box, but hear me out as this is
> likely the best way to satisfy everyone's requirements.
> Recap: The community needs additional github permissions in order to
> integrate CI in order to maintain code quality.  The ASF does not have
> enough granular control via github to give permissions on the
> apache/cloudstack repository without giving the permissions across the
> entire github apache org, which they are presently not comfortable with.
> What if we did the following:
> - Setup the 'cloudstack' github org so both the ASF and the community have
> 'owner' role representation.
> - The apache/cloudstack repo is transferred to the cloudstack/cloudstack
> repo.  This will move all of the PRs and everything over to the
> cloudstack/cloudstack repo and will also setup redirection from
> apache/cloudstack to cloudstack/cloudstack.
> - This allows for the ASF and the community to work together to establish
> the github permissions which make the most sense for the cloudstack project
> without being bound by its implications on other projects.
> - The official ASF repo would still be the source of truth and the
> cloudstack/cloudstack repo would be a mirror of it.  There are probably
> some details in this that we will need to address to make sure everything
> is consistent with the ASF requirements.
> - There will only be one cloudstack repository on which to contribute as a
> community member, so there will be no confusion introduced and there will
> be no segmentation of the community.
> - The cloudstack/cloudstack repo would still be an official ASF project, so
> no need for rebranding or worrying about the unpleasant logistics of a
> "fork".
> I am sure I have not thought through all the details and I am sure there
> are some gotchas that we have to sort out, but I think this is a real
> viable stepping stone towards being able to satisfy both parties
> requirements while keeping the community strong and headed in the same
> direction.
> What do you all think?
> *Will STEVENS*
> Lead Developer
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w *|* tw @CloudOps_
> On Thu, Mar 17, 2016 at 8:44 PM, Ahmad Emneina <> wrote:
>> +BCC: David Nalley for possible guidance.
>> Apache infra stated that 'The VP' dictated the policy to not allow
>> 'repo:status' across the board for projects. Has anyone tried to engage the
>> VP, in order to get them to have a closer look at this policy? It appears
>> to be no way to exploit that function maliciously... so hopefully they
>> could allow for this to be enabled.
>> $0.02
>> On Thu, Mar 17, 2016 at 4:46 PM, Erik Weber <> wrote:
>>> On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann <>
>>> wrote:
>>>>>> The other thing is - is the new Cloudstack GitHub organization the
>>>>>> result of a subset of the PMC going off and doing this -
>>>>> I am not sure why you say subset. Let’s try to avoid polemics.
>>>> I’m not trying to attack.
>>> This is not the result of people getting together and saying 'hey, we
>>> should fork and work somewhere else, that'd be fun!', but rather
>>> 'hey, we are currently unable to do what we need to do, and none of our
>>> attempts of getting assistance have resulted in anything. what can we
>> do?'.
>>> On January 27th 2016, Schuberg Philis (SBP), a company with many
>> CloudStack
>>> contributors/committers/pmcs, announced that they are 'jumping ship,
>>> forking the code and going their own way'.  (that's my wording, not
>> theirs)
>>> Take a look at our git commit history before and after that date. Notice
>>> anything?
>>> Most, if not all, are trivial commits to fix typos, simple mistakes etc.
>>> and not code changes.
>>> This may be rude to everyone else, but the fact is that after 4.5 SBP
>>> (there are a few exceptions) has done more or less everything when it
>> comes
>>> to testing code and gatekeeping the code base. And they did a very good
>> job
>>> at it.
>>> Frankly I am surprised they even coped with it that long.
>>> Apache CloudStack now has a fork (Cosmic), that's not bound by ASF
>> policies
>>> and it's lack of progress when it comes to providing the tools necessary.
>>> When (or if -- with their own governing they don't have to call it a
>>> specific version) SBP release an official version of Cosmic, it would
>>> surprise me if not a lot of CloudStack users would atleast try it out.
>>> I am pretty sure that I am going to.
>>> And wha-bang, there (potentially) goes your community, because there
>>> already is a better option out there.
>>>> I asked a simple question - how many/who in the Apache CloudStack PMC
>>>> is intent on using this new Cloudstack GitHub organization? Not an
>>>> attack, a question that I still don’t have an answer to.
>>> The answer would most likely be 'anyone and everyone'.
>>> Contrary to what you might believe, this is being done to /help/
>>> CloudStack, not hurt it. Atleast that is my intention by participating.
>>> In case you are unfamiliar with Apache CloudStack, it is a beast.
>>> Unlike many typical ASF projects you cannot just unpack the tarball, run
>>> 'make test', wait a few minutes and have it properly tested.
>>> Testing Apache CloudStack requires a broad variety of physical hardware,
>>> network appliances, storage solutions and least but most importantly
>> pretty
>>> much every hypervisor that is being used out there.
>>> A subset of the test tasks we have take multiple hours to run and only
>>> tests a small fraction of the total codebase.
>>> Pre 4.6, the Apache CloudStack community had a little to loose discipline
>>> on committing to the codebase.
>>> Testing was optional, and hardly done.
>>> We had multiple versions that had major flaws in them, discovered right
>>> after release as people tried to use it -- even for the most basic
>>> operations.
>>> For the 4.6 release we decided that from now on, every commit would have
>> to
>>> be looked through by two different persons, saying they approve it, and
>>> tested by a minimum of one.
>>> And it worked, the voting process improved, we released rapidly and with
>>> far less issues than previously (no software is bug free after all).
>>> As mentioned, we require that code changes (be it improvements, fixes or
>>> new features) are tested before they are allowed to be committed.
>>> Which means that anyone wanting to interact (with code) have to do it
>>> theirselves at the moment, and that is _NOT_ an easy task.
>>> Which again means that no matter how good your intention is, your PR is
>> not
>>> going be merged.
>>> What kind of Community treatment is that?
>>> The way I see it there is only one solution to this -- we need better
>>> testing, and to automate that we need more access to GitHub.
>>> There are two ways to do that;
>>> 1) By being granted certain permissions to the apache/cloudstack
>>> repository.
>>> 2) By doing it somewhere else where we have those permissions.
>>> Will Stevens asked infra [1] for a small subset of permissions -- none of
>>> which should be any real risk for disasters, and got rejected.
>>> That rules out option #1.
>>> This turned out to be a long, and emotional email, please don't take any
>>> grunts personally -- they are not meant to be.
>>> [1]
>>> --
>>> Erik

View raw message