Date
1 - 2 of 2
Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing
David Meyer <dmm@...>
All,
During the board call this afternoon I outlined the issues that we
have been facing around repositories, projects and committer lists.
After an hour of thoughtful and spirited discussion the following
items were decided by the ODP Board:
First, two things were stipulated: (a). The Dixon-Erickson
OpenDaylight Merged Controller Proposal ("DE proposal") is the
consensus framework for moving forward, and (b). that the new
project/repository idea in which the two controllers were disassembled
then reassembled to build a new controller will *not* be pursued. As a
result either the OpenDaylight Controller ("controller") or the
OpenDaylight SDN Controller Platform ("net-virt-platform") will be
the starting point.
Given that, the following process was agreed upon:
(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.
(ii). Using code base selected in (i). find volunteers to flesh out
each functional block of the DE proposal. For each functional block we
will also need a design for integration with the larger system. Note
that those who do this work are likely candidates to become committers
(growing committer lists organically).
(iii). Decide on a timeframe during which this plan can be executed,
noting that we need to have this done in a timely fashion.
Thanks,
--dmm
During the board call this afternoon I outlined the issues that we
have been facing around repositories, projects and committer lists.
After an hour of thoughtful and spirited discussion the following
items were decided by the ODP Board:
First, two things were stipulated: (a). The Dixon-Erickson
OpenDaylight Merged Controller Proposal ("DE proposal") is the
consensus framework for moving forward, and (b). that the new
project/repository idea in which the two controllers were disassembled
then reassembled to build a new controller will *not* be pursued. As a
result either the OpenDaylight Controller ("controller") or the
OpenDaylight SDN Controller Platform ("net-virt-platform") will be
the starting point.
Given that, the following process was agreed upon:
(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.
(ii). Using code base selected in (i). find volunteers to flesh out
each functional block of the DE proposal. For each functional block we
will also need a design for integration with the larger system. Note
that those who do this work are likely candidates to become committers
(growing committer lists organically).
(iii). Decide on a timeframe during which this plan can be executed,
noting that we need to have this done in a timely fashion.
Thanks,
--dmm
Chris Wright <chrisw@...>
* David Meyer (dmm@...) wrote:
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.
(i). Disambiguate the starting point for the DE proposal. ThisWhile my OSGi knowledge is limited, my understanding is that we can
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.
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.