Hi Dave ,
IP clearance is required only when your feature would have been developed
outside the community intervention and you want to propose that feature to be
merged with the asf/master branch. If you have happened to discuss the
functional spec for your feature with the community and answered the queries if
any one might have in the community and done all your code commits through
review requests , IP clearance would not be required at all .
For your remaining queries -
See comments below -
[Dave] - * 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
[Pranav] - I wouldn't comment on the size of the patch .If your code is
self-explanatory and clean , reviewing either small patches or a big one should
not be a big problem . But I would still recommend to send smaller patches for
reviews since it's easier for the people in the community to scan through them
easily and suggest amendments if required.
[Dave] - * However, if chunks / reviews are too big, is there an issue of
development "appearing" to have happened outside of the ASF repo?
[Pranav] - If you have been sending review requests for all the code which has
gone into your github repo , it should not create an issue since after all you
have done your duty of making all your development in the community . Just that
, there should not be even a small chunk of code which has been merged without
having the community know about it - that's the criteria , I reckon .
[Dave] - 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?
[Pranav] - If your plugin is not aimed for 4.1.0 and given that you are not
having committer rights , I believe , then your code won't be merged with
asf/master until the 4.1.0 release is over . Since you would just be generating
the patches and sending them for reviews. The committer would not merge them
with as/master and keep them on hold until that period .
Perhaps someone in the PPMC ( may be David Nalley or Chip or Animesh ) can
better answer your last query .
Thanks,
Pranav
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Cahill
Sent: Monday, January 21, 2013 3:10 PM
To: Pranav Saxena
Cc: [email protected]
Subject: Re: [PROPOSAL] Networking plugin to integrate the MidoNet SDN platform
with CloudStack
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]<mailto:[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]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Dave
Cahill
Sent: Monday, January 21, 2013 1:27 PM
To:
[email protected]<mailto:[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]<mailto:[email protected]>> wrote:
> > -----Original Message-----
> > From: [email protected]<mailto:[email protected]>
> > [mailto:[email protected]<mailto:[email protected]>] On Behalf Of
> > Dave Cahill
> > Sent: 21 January 2013 10:46
> > To:
> > [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>%3E
> > >
> > > [2] http://www.midokura.com/midonet/
> > >
>
