cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cahill <dcah...@midokura.com>
Subject Re: [PROPOSAL] Networking plugin to integrate the MidoNet SDN platform with CloudStack
Date Tue, 22 Jan 2013 01:41:28 GMT
Hi Pranav,

Thanks, that makes things a lot clearer.

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

Keeping a large number of commits on hold (reviewed, but not in the ASF
repo) sounds like it could make merging difficult later. If anyone has
clarifications or alternatives, I'd be interested.

Thanks,
Dave.






On Mon, Jan 21, 2013 at 7:02 PM, Pranav Saxena <pranav.saxena@citrix.com>wrote:

> 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:* dcahill@midokura.jp [mailto:dcahill@midokura.jp] *On Behalf Of *Dave
> Cahill
> *Sent:* Monday, January 21, 2013 3:10 PM
> *To:* Pranav Saxena
> *Cc:* cloudstack-dev@incubator.apache.org
>
> *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 <pranav.saxena@citrix.com>
> 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/cloudstack-dev@incubator.apache.org/msg02776.html.
>
> Thanks,
> Pranav****
>
>
> -----Original Message-----
> From: dcahill@midokura.jp [mailto:dcahill@midokura.jp] On Behalf Of Dave
> Cahill****
>
> Sent: Monday, January 21, 2013 1:27 PM
> To: cloudstack-dev@incubator.apache.org
> 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 <
> sateesh.chodapuneedi@citrix.com> wrote:
>
> > > -----Original Message-----
> > > From: dcahill@midokura.jp [mailto:dcahill@midokura.jp] On Behalf Of
> > > Dave Cahill
> > > Sent: 21 January 2013 10:46
> > > To: cloudstack-dev@incubator.apache.org
> > > 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 <dcahill@midokura.jp>
> > 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/%3C20120813142751.23840.41217@reviews.apache.org%3E
> > > >
> > > > [2] http://www.midokura.com/midonet/
> > > >
> >****
>
> ** **
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message