[OpenDaylight Discuss] Merged controller project code location

Raza, Sarwar S. (HP Networking - ATG) sarwar.s.raza at hp.com
Mon May 13 19:38:23 UTC 2013

Hi all,
A third (new) repo to house the merged controller effort, COUPLED with a commensurate initial committer list comprised of individuals spearheading said effort makes complete sense. Not sure I understand why this would be the long pole in the tent, relative to the other items Rob has pointed out below.

+1 to Dave's new repo proposal.


Sarwar Raza
Director, Cloud Networking & SDN
Advanced Technology Group - HP Networking
Hewlett-Packard, Littleton MA
+1 (978)-760-3701 (mobile)
sarwar.raza at hp.com<mailto:sarwar.raza at hp.com>

From: discuss-bounces at lists.opendaylight.org [mailto:discuss-bounces at lists.opendaylight.org] On Behalf Of Rob Sherwood
Sent: Monday, May 13, 2013 3:26 PM
To: Thomas Nadeau
Cc: discuss at lists.opendaylight.org
Subject: Re: [OpenDaylight Discuss] Merged controller project code location

Hi all,

First, I wanted to say that I agree with Dave that a third/new repo is the right thing, but not just for "appearances" but actually for coding sanity.  Everyone seems to agree that existing APIs in the SAL need to be updated (and in some cases changed) and if you look at the modules in Colin's diagram, almost all of them  need to be ported or rewritten.  So, if people start working in one of the existing repos, it will be _very_ hard to track which modules and APIs are stable and which ones still need to be rewritten.  I see the new repo as method of saying "this code is done, it's ok to build on it" where the same cannot be said of building in either input repo.  In other words, without a new repo, people may have to port and re-port their work as APIs change out from under them.

As a new repo for pushing out the Q3 deadline, I'm not sure I understand the concern here.  From my concern above, I see *not* having a new repo as a bigger danger to the Q3 deadline, but the point is a bit strange anyway.  In my mind, the long poles for the Q3 deadline are (1) doing all of the porting and rewriting work described by the D-E proposal (independent of the repo) and (2) deciding what deliverable people want for Q3 and working towards that (e.g., people have suggested a quantum virtualization stack, others have suggesting a WAN TE application -- these will take work).  IMHO, which repository we commit the code to is hardly the most important impact on the timeline.

- Rob

On Mon, May 13, 2013 at 4:29 AM, Thomas Nadeau <tnadeau at juniper.net<mailto:tnadeau at juniper.net>> wrote:

From: Colin Dixon <ckd at us.ibm.com<mailto:ckd at us.ibm.com>>
Date: Sunday, May 12, 2013 11:03 PM
To: David Erickson <daviderickson at cs.stanford.edu<mailto:daviderickson at cs.stanford.edu>>
Cc: "discuss at lists.opendaylight.org<mailto:discuss at lists.opendaylight.org>" <discuss at lists.opendaylight.org<mailto:discuss at lists.opendaylight.org>>
Subject: Re: [OpenDaylight Discuss] Merged controller project code location

While I agree with David's goals of political neutrality, avoiding a winner, solely merit-based committers, carefully reviewing all of the code, and having the project be different from either initial contribution, I'm not sure that starting a third code base gives us any of these and it comes at some costs.

As far as political neutrality and merit-based committers, while I might hope that a third code base would naturally cause these to arise, I think that the reality is likely to be different. I worry about a land grab for the new battlefield. While in some ways it might be good to create some kind of race for putting in as much of the new code as possible to encourage contributions, I'm not sure this is the right way to do it.

I think the current proposal makes it very clear that neither code base is being anointed a "winner", but in fact we are drawing from both where they are strongest. Further, having spent time inside of both code bases, I think that both will be significantly altered by the process. In the case of the net-virt-platform, the formal introduction of the SAL into the components we use will make them categorically different and I also think that as developers go through both code bases passes will bring more rigor and cleaner style to the code. The controller project code seems like it might benefit more from this at the moment.

On that note, reviewing and cleaning all of the code is something that it's impossible to say is a bad thing, but I really don't think that we will have the time or patience to review all of the code line-by-line as we pull it together into a single entity. I think it's much more likely that there will be bulk code shuffles at a coarse granularity followed by another pass or two to finesse things into place and hunt down bugs.

Lastly, I think there is a lot of value in having a code base that works and does something to begin with rather than starting from scratch where significant work needs to be done before the code comes up, runs and does something useful.

All of that being said, I'm not a zealot on this point and if the community genuinely believes that starting a new project will solve these problems. I will help the process as best I can.

That is precisely the point I just made my my last note. It is hard to justify a "code cleanse" just for the sake of appearances because that will take a significant amount of time with limited return on that investment. What we could do is ask that committers clean things as they go with the goal of having it in that state say by FSC 1.  What I adamantly want to avoid are further delays in my coders working on their projects because people need to do busy work such as rename functions and files; that is just going to slow our momentum.   I have also given some thought to the third code repository, and that similarly seems to have limited value in my mind right now.



-----discuss-bounces at lists.opendaylight.org<mailto:-----discuss-bounces at lists.opendaylight.org> wrote: -----
To: discuss at lists.opendaylight.org<mailto:discuss at lists.opendaylight.org>
From: David Erickson
Sent by: discuss-bounces at lists.opendaylight.org<mailto:discuss-bounces at lists.opendaylight.org>
Date: 05/11/2013 02:51PM
Subject: [OpenDaylight Discuss] Merged controller project code location
Hi Everyone-

I wanted to take a minute and clarify one of the differences that Colin
and I had in our proposal for merging the current controller projects,
and why I took the position I did.  The text from the proposal states:

"We differ in our thoughts on where to house the new code. David
recommends that a
new project and repository be created to contain this new combined code
while Colin
feels that the appropriate place to address these concerns is the life
cycle requirements
for projects to have (merit-selected) committers from multiple companies
for them be
promoted to certain life cycle stages."

There are multiple reasons I believe that a new repository should be

1) It is politically neutral
1) It avoids even the appearance that one of the existing projects was
chosen as the 'winner'
2) Commit rights and project control start from a clean slate, placing
the contributors of the two existing projects, and new contributors on
an equal playing field
3) Related to #2, it provides a bit of a forcing function for
contributors to work together more closely using the public
infrastructure (dev mailing lists, bugtracker, Gerrit, etc) because
there would not be a single incumbent making all the decisions on what
to accept/reject
4) It also requires a review for each chunk of code that is to be pulled
into the new repository, which may/may not happen (or at least be
delayed) for code that was already in an existing repository
5) The merged code will make the final controller substantially
different from either of the existing projects

Beyond these points I would also argue that it should appeal to your
common sense as the 'right' thing to do.  As an open source community it
is our responsibility to ensure we create the best software possible,
hence our proposal for merging the best existing components together
from contributed code to form a new controller.  It is also our
responsibility to ensure that those participating in a project (via code
contributions and other mechanisms) receive a proportional level of
influence or control over the project.  It is hard enough to achieve
this with physically separated engineering teams and individuals under
the best of circumstances, let alone starting a project off where one
team has been working on the code for a long time and could (rightfully)
feel like they own the code base and are the gatekeepers to modifying
it.  This is crucial to get right at the start of this controller
project, because it will set the tone for OpenDaylight as an
organization going forward.

I want to also be absolutely clear that my viewpoint would remain the
same if Colin had recommended using the other contributed controller
project as the repository to start with, my intention is not to pick on
any particular organization here.

Lastly, as stated in the proposal "We would like to explicitly ask for
feedback from *all* consortium members", I would appreciate any and all

Discuss mailing list
Discuss at lists.opendaylight.org<mailto:Discuss at lists.opendaylight.org>

Discuss mailing list
Discuss at lists.opendaylight.org<mailto:Discuss at lists.opendaylight.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/discuss/attachments/20130513/5fffcb3a/attachment-0001.html>

More information about the Discuss mailing list