We can see if we can get the 'apache-cloudstack' org on github if that is preferred. No reason not to try...
What is currently at 'cloudstack/cloudstack' is NOT what we are proposing going forward. This is currently an actual fork which was put in place simply for the purpose of testing. We would be deleting that repository and ideally moving the 'apache/cloudstack' to the current 'cloudstack/cloudstack' repo location (or 'apache-cloudstack/cloudstack' if we get that org). I understand that the current fork at 'cloudstack/cloudstack' is probably adding some confusion to this conversation. I think we are on the same page. I think we just need to start ironing out the actual logistical and technical details for how to move forward. Cheers, *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 1:30 PM, Sam Ruby <ru...@intertwingly.net> wrote: > On Fri, Mar 18, 2016 at 1:09 PM, Will Stevens <wstev...@cloudops.com> > wrote: > > Hi Sam. Thank you very much for joining the conversation. We look > forward > > to working with you and appreciate your guidance on the matter. > > > > Just a quick note regarding my suggestion and the 'perception' concern > you > > raised. I am actually proposing that we do an ownership transfer of the > > 'apache/cloudstack' repo to the 'cloudstack/cloudstack' repo. This means > > that it will not be a fork of 'apache/cloudstack' because if you tried to > > access that repo it would redirect to 'cloudstack/cloudstack', it will > only > > show the "Mirror of Apache CloudStack". > > > > Other benefits of this is that all the PRs (180+) will automatically be > > moved to the 'cloudstack/cloudstack' repo making it easier for everyone > > involved to understand where people are expected to open PRs. > > I may have been unclear. I think we are talking about two separate things. > > Regarding the "organization" (the first cloudstack in > cloudstack/cloudstack), if there is a technical means to grant you the > access you should have to control your repository(-ies), then staying > in apache would arguably be better; but so far that avenue has been > explored and looks to be a dead end. So moving to a separate > organization makes sense. I think I would prefer that organization to > be apache-cloudstack for reasons that I am about to get to, but I'm > not stuck on that. > > I'm more concerned that the page is indistinguishable from a fork, and > gives no indication of official status. That may be OK for a work in > progress, but isn't ideal as a final solution. I'll share that I've > heard (second and third hand) reports of people who only have heard of > there being an "external fork", and have drawn incorrect conclusions > from that. I think we need to be careful about how this is explained, > as perceptions matter. > > By contrast, if you go to: > > https://github.com/apache/whimsy > > What you will see in place of "Mirror of xxx" is "Apache Whimsy". I > grant you that it is a small thing, and there is technically nothing > wrong with what is there now; but I claim that we can and should do > better. From a perception perspective, it is the difference between > individuals on the CloudStack PMC leaving the ASF, and the ASF > expanding support for repositories hosted on GitHub. I'd like to > pursue the latter, and if there are any obstacles (technical or > otherwise) would like help flatten those issues. > > - Sam Ruby > > > I will review what is being done with Whimsy to get a better idea how > that > > project is being handled. > > > > Thanks again for joining this conversation... > > > > *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 11:27 AM, Sam Ruby <ru...@intertwingly.net> > wrote: > > > >> On Fri, 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? > >>> > >> > >> +1 > >> > >> I'm pleased to see this being discussed on the dev list; and I'm ashamed > >> that the board hasn't been more responsive. Suffice it to say that this > >> issue now has the board's attention. > >> > >> On one hand, I'm a bit concerned that things are moving too quickly; and > >> on the other hand I feel that it is time to rip the bandage off. So I > >> would like to simultaneously encourage you (collectively) to think > further > >> outside of the box, and yet not be too impatient despite the previous > lack > >> of response. I'm the one that pushed through the approval of the Whimsy > >> experiment, and I'm willing to help here. > >> > >> What would you be able to do if the git-dual experiment were expanded to > >> CloudStack that you couldn't do with the proposal above? I suggest that > >> you take full advantage of the fact that people are now listening. > >> > >> Be aware that perception matters. If you go to > >> https://github.com/cloudstack/cloudstack, you will see in small print > >> "forked from apache/cloudstack" and then in slightly larger font > "Mirror of > >> Apache Cloudstack". There should be an edit link on the latter for the > >> owners of the organization, I'd like to discuss what should be there. > >> > >> I personally believe that the ASF has a demonstrable interest in being > >> able to establish provenance, but I don't believe that taking over > control > >> of the ability of projects to set up Travis and other integrations is a > >> necessary consequence of that. But overall I agree that if granularity > of > >> control for a single GitHub organization is an issue, then having > multiple > >> GitHub organizations needs to be explored as an option. > >> > >> How can I help? I'd like to bring this proposal back to the board for > >> wider review so that nothing important is missed. If there are issues > that > >> come up, I will help flatten them. > >> > >> - Sam Ruby > >> >
