1. TSC
  2. Topics

[OpenDaylight Discuss] Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing

Rob Sherwood
 

I want to re-iterate Big Switch's position that we're against "top down" TSC or Board votes on technical design and implementation questions, and we feel the current issue falls in to that category.  The communities we've found successful are the ones that have strong processes, but rely on volunteerism and leaders close to the code to drive technical direction.

I understand the concern that we've given ourselves a deadline of Q3 to produce an initial release.  However, on behalf of Big Switch, we feel that in the trade-off between the scope, date and community building, we'd put community first.  Let those close to the code come together and sort this out, and keep our role as a TSC focused on removing the barriers that would prevent that from happening bottoms-up.

So, even though I personally believe that the net-virt code base is the better technical starting point to get the most mature code fastest, I'm going to _abstain_ from tomorrow's vote and would encourage the other TSC members who are concerned about this process to do likewise.  There is are healthier ways to solve this.

- Rob
.

PS @Chris: the feature of pushing modules to nexus is actually a function of maven, not OSGI 


On Wed, May 15, 2013 at 10:13 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
> (i).   Disambiguate the starting point for the DE proposal. This
> starting point can be either the "controller" or "net-virt-platform"
> code base (again, the third project/repository is not a candidate).
> Note that the current list of committers for whichever code base will
> *not* be carried forward. The point here is to decouple the issue of
> committers from the code base.
>
> The TSC will vote on the starting point as the first order of business
> during tomorrow's call.

While my OSGi knowledge is limited, my understanding is that we can
develop bundles in any repo, push to nexus, and combine them via
distribution/pom.xml as a part of a build (could be part of release
engineering).  So I'd like to continue understanding the technical
issues associated w/ making, e.g. net-virt-platform or even third repo
modules into bundles and including them as dependencies regardless of
their source genesis before we (TSC) take any invasive[1] action.  Put
another way...taken to the extreme, I believe each OSGi bundle could
end up in its own repo (meaning the repo discussion has little merit).

thanks,
-chris

[1] For the record, I believe this is antithetical to an open community
(and not in the purview of the TSC) unless the vote is simply to clarify
the TSC's recommendation.
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
Chris Wright <chrisw@...>
 

* Rob Sherwood (rob.sherwood@...) wrote:
PS @Chris: the feature of pushing modules to nexus is actually a function
of maven, not OSGI
Yes, I know. The point being that the bundle <-> repo connection is
papered over by as build.

1 - 2 of 2