Hi Pranav, Thanks for the reply, that makes sense. I've used the non-committer workflow for small patches before, and it works well.
One concern I have is avoiding the IP clearance issues I'm seeing so many messages about on this list. For example, here's a quote from "Concerns about where development has happened" (http://markmail.org/message/nu4f6tphsnsv7ls6): > There's also an IP issue here. If you are developing in the ASF repo, > we are relatively assured that you are complying with the CLA that you > signed when you were invited as a committer. Using the non-committer workflow, I wouldn't be developing in the ASF repo, which raises a few questions. * Granularity of commits back to the ASF repo * IMO, when pushing back to the repo, the commit should be big enough that it's worth the reviewer's time - lots of tiny reviews would be a burden on the reviewer * However, if chunks / reviews are too big, is there an issue of development "appearing" to have happened outside of the ASF repo? * Branch to use * The workflow seems to imply that non-commmitters should work off a fork of ASF "master" branch * However, this may not make sense - for example, this plugin is not aimed for 4.1.0, so commits to it probably shouldn't be sent back to master * Should there be a separate branch for the plugin in this case? If so, should I just request that a committer create one? Thanks, Dave. On Mon, Jan 21, 2013 at 5:04 PM, Pranav Saxena <[email protected]>wrote: > You need to follow the non-committer workflow - > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Noncommitterworkflow > and fork a asf/incubator-cloudstack repo from github on your local > workspace and send review requests from there. > > Further discussions about the github non-committer workflow here - > http://www.mail-archive.com/[email protected]/msg02776.html. > > Thanks, > Pranav > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dave > Cahill > Sent: Monday, January 21, 2013 1:27 PM > To: [email protected] > Subject: Re: [PROPOSAL] Networking plugin to integrate the MidoNet SDN > platform with CloudStack > > Hi Sateesh, > > Thanks for the reply. > > I've submitted a few patches over the past while, but I don't have > committer privileges yet. > > If the plugin should be developed on an ASF repo branch, and committer > privileges are required to do that, what's the next step? > > Thanks, > Dave. > > > > On Mon, Jan 21, 2013 at 4:37 PM, Sateesh Chodapuneedi < > [email protected]> wrote: > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf Of > > > Dave Cahill > > > Sent: 21 January 2013 10:46 > > > To: [email protected] > > > Subject: Re: [PROPOSAL] Networking plugin to integrate the MidoNet > > > SDN platform with CloudStack > > > > > > Hi, > > > > > > The Functional Spec is now available here: > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Midokura+Netw > > > orking+Plugin > > > > > > The New Feature ticket is here: > > > https://issues.apache.org/jira/browse/CLOUDSTACK-996 > > > > > > The main outstanding questions are: > > > > > > Where should the feature be developed? > > > Should it be on a branch off the ASF repo, and if so, are > > committer > > > privileges required? > > Yes, committer privileges are required > > > > > > > > Testing > > > How does testing work for plugins which interface with tech > > > which is > > not > > > freely available? > > > Suggested approach: Plugin creator handles plugin testing, and > > > the > > plugin is > > > setup as "nonoss" in the pom.xml (therefore not compiled by > > > default) > > > > > > Comments and questions appreciated. > > > > > > Thanks, > > > Dave. > > > > > > > > > > > > On Thu, Jan 17, 2013 at 1:59 PM, Dave Cahill <[email protected]> > > wrote: > > > > > > > Hi all, > > > > > > > > There were a few mentions on the list over the past few months [1] > > > > about creating a plugin to integrate the MidoNet [2] SDN platform > > > > with > > > CloudStack. > > > > > > > > Since processes for new features have become better-defined since > > > > the initial discussion, I'd like to start ticking the boxes to > > > > make sure the plugin is created with community involvement: > > > > creating and discussing the Functional Spec and design, creating a > > > > Jira ticket to > > track > > > progress etc. > > > > > > > > I would like to aim the plugin for the CloudStack 4.2.0 release. > > > > > > > > Here's my understanding of next steps. > > > > > > > > * dcahill to create a Functional Spec Should be a child of > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design+Docume > > > nt > > > > s+Not+Committed+to+a+Release > > > > Should follow this template > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design+Docume > > > nt > > > > +Template > > > > > > > > * dcahill to create a "New Feature" item to track progress within > > > > the CLOUDSTACK project here: > > > > https://issues.apache.org/jira/browse/CLOUDSTACK > > > > > > > > As the items above progress, I'll keep the list updated. I look > > > > forward to discussing the plugin plans - any questions you have, > > > > just > > let me > > > know! > > > > > > > > Thanks, > > > > Dave. > > > > > > > > > > > > > > > > [1] Initial commit of MidoNet plugin skeleton: > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-cloudstack- > > > dev/2012 > > > > 08.mbox/%[email protected]%3E > > > > > > > > [2] http://www.midokura.com/midonet/ > > > > > > >
