My view on this is that cloudstack-extras should be for other projects' integration with cloudstack that's outside of cloudstack's api only. Cloudstack-extras should not be governed by us as well.
Just because it's a different language but is part of cloudstack (i.e. Donal's question on .net) should not be considered outside of cloudstack. We have plenty of languages different from java already, including python and shell scripting, sql scripts, C at one point, and Visual Studio for the password changer. --Alex > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Friday, January 04, 2013 11:27 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] Managing the cloudstack-extras github organization > > On Fri, Jan 4, 2013 at 2:16 PM, Chiradeep Vittal > <chiradeep.vit...@citrix.com> wrote: > > > > > > On 1/4/13 6:32 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > > > >>On Thu, Jan 3, 2013 at 5:17 PM, David Nalley <da...@gnsa.us> wrote: > >>> On Thu, Jan 3, 2013 at 11:39 AM, Chip Childers > >>> <chip.child...@sungard.com> wrote: > >>>> Hi all, > >>>> > >>>> Although this list is officially the Apache CloudStack dev list, I > >>>> think it's also the right place to collaborate about the > >>>> cloudstack-extras Github organization ( > >>>> https://github.com/CloudStack-extras ). Any issues using this list to > >>>> discuss cloudstack-extras? > >>>> > >>>> If no issues... > >>>> > >>>> I'd like to propose that we effectively equate Apache CloudStack > >>>> committer status to having the right to have commit permissions to the > >>>> repos in that Github organization. Any objections to that? > >>>> > >>>> I'd further like to propose that projects from non-committers, that > >>>> want to be moved to CloudStack-extras, are initially created by the > >>>> contributor under their own organization or personal account, and then > >>>> moved into Cloudstack-extras after a discussion on this list. > >>>> > >>>> For projects under the cloudstack-extras org, I'd propose that we use > >>>> the standard github pull request mechanism to pull in updates. > >>>> > >>>> Last, I'd like to propose that we change the Cloudstack-extras org > >>>> profile "location" field from "Not affiliated with the Apache > >>>> CloudStack project" to "These are not projects of the Apache Software > >>>> Foundation". > >>>> > >>>> Thoughts? > >>>> > >>>> -chip > >>> > >>> > >>> So currently these are largely separate efforts. The folks working on > >>> knife-cloudstack or puppet-cloudstack largely aren't directly > >>> contributing to Apache CloudStack. (with a few exceptions) These > >>> projects have either no real community or their own community > >>> (knife-cloudstack being the example there). To be clear - I'd > >>> personally prefer that these go to live elsewhere, and we get rid of > >>> most of the repos in that org. > >>> > >> > >>Fair point about those non-project community repos. > >> > >>> I am also somewhat concerned about providing governance for these > >>> external projects. If we (the project) do want to provide governance, > >>> we can trivially get additional git repos on ASF hardware. > >>> > >> > >>Perhaps that's the path we need to take... What caused me to ask the > >>question was the discussion of the .NET CloudStack API binding that's > >>under development. We discussed putting that in cloudstack-extras, > >>hence me raising the question of governance around the github org. > >> > >>However, your alternative may be more logical. We coule handle > >>projects like that (and even potentially things in the tools folder of > >>the CS codebase) by creating separate repos (and even possibly having > >>different releases). > >> > >>> --David > >>> > > > > Quite confused here. > > Is the proposal to have them hosted on ASF, but at the same time NOT > > part of CloudStack? > > If it is not part of CloudStack, should we care about governance? > > > > My point was: > If we provide governance - they should be at the ASF. > If they aren't at the ASF we should likely not provide governance. > > --David
