All, +1 to Will’s proposal/approach. All we are really talking about is rehoming the apache/cloudstack repository mirror to cloudstack/cloudstack. The canonical repository would remain the official Apache git repository hosted on Apache owned hardware. Therefore, we would maintain our current PR merge process [1] that merges the PR branch locally and pushes it to the Apache git repository. If re-home the Github mirror, I think it should remain read-only mirror where we have the ability to grant privileges to our CI system to close PRs.
I would also add that currently, the cloudstack organization is owned by individuals who happen to be Apache CloudStack PMC members and committers. In my opinion, in order for it to work in the long term, we would need a governance policy that transferred ownership to our PMC or Apache Infra. Our interest is not the create a fork, but provide our community with the ability to exploit an extremely powerful tool for collaboration and source management. Finally, I believing having a dedicated cloudstack Github organization may be a means to expand the community. Currently, we have no place to easily host subprojects (e.g. cloudmonkey, marvin, etc). With a dedicated organization, we could consider inviting other complementary projects such configuration management recipes/playbooks and language clients to place their repos in the cloudstack organization. For users, they would have a central, community sponsored place to find all things cloudstack and we further improve our collaboration with the authors/maintainers of these projects. In short, I think Will lays out the approach very clearly. There is **no** intention or action to fork Apache CloudStack. Instead, we simply want to re-home apache/cloudstack repository mirror to cloudstack/cloudstack without changing any other processes. Most importantly, this change can be made without compromising the provenance of the codebase because, as we do today, commits would only occur on the Apache git repo. Thanks, -John [1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655 > [ShapeBlue]<http://www.shapeblue.com> John Burwell ShapeBlue d: +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411> e: john.burw...@shapeblue.com | t: <mailto:john.burw...@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK [cid:image6929de.png@d359d3b7.49a57074] Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. On Mar 18, 2016, at 3:40 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > 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. > > -Sebastien > >> On Mar 18, 2016, at 4:37 AM, Will Stevens <wstev...@cloudops.com> 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 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 >>>> >>> > Find out more about ShapeBlue and our range of CloudStack related services: IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
