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 cloudops.com *|* tw @CloudOps_ On Thu, Mar 17, 2016 at 8:44 PM, Ahmad Emneina <aemne...@gmail.com> 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 <terbol...@gmail.com> wrote: > > > On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann <mattm...@apache.org> > > 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] https://issues.apache.org/jira/browse/INFRA-11429 > > > > > > -- > > Erik > > >
