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 Fri, Mar 18, 2016 at 9:36 AM, Paul Angus <paul.an...@shapeblue.com> wrote: > +1 Sounds like a plan. > > > > Paul Angus > VP Technology , ShapeBlue > > > t: @cloudyangus<tel:@cloudyangus> > > e: paul.an...@shapeblue.com<mailto:paul.an...@shapeblue.com> > | w: www.shapeblue.com<http://www.shapeblue.com> > > > > > > From: John Burwell [mailto:john.burw...@shapeblue.com] > Sent: Friday, March 18, 2016 1:32 PM > To: dev@cloudstack.apache.org > Subject: Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull > request: Is the project attempting a fork on Githu...) > > 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<mailto: > 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 > <mailto: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 > <mailto: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 > <mailto:terbol...@gmail.com>> wrote: > >>> > >>>> On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann <mattm...@apache.org > <mailto: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/> > 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/> >
