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 >>
