Date 1 - 3 of 3
[controller-dev] [yangtools-dev] Proposal to spin out MD-SAL
On Thu, Apr 2, 2015 at 1:10 PM, Colin Dixon <colin@...> wrote:
It should actually reduce the cross patch issue as things get moved into more logical groupings.
It should make it a fair bit easier, as you will have distinct logical components, together, and without a bunch of unrelated stuff to wade through.
1) Build times - local, merge, verify
2) Channels of patches in gerrit - you can easily see what goes what project... better granularity there
3) Better clustering of committer expertise
4) Well defined scope
5) Simpler path to committerness (a logical outgrowth of better defined scope)
We are seeing some of the benefits of these sorts already in neutron, which was using the 'subdir' method you suggested,
and got a shot in the arm along these axis when it spun out.
Basically we tried 'subdir' with neutron, and then we tried 'spin out a project'. It turns out that 'spin out the project' is *much* better for these reasons and probably
several others I'm forgetting. (oh, it also seems to encourage more participation as well... a lovely side benefit :) ).
toggle quoted message Show quoted text
So, I agree with all of your points at the end (1-5+).--Colin
However, I still feel like we haven't heard a compelling case as to why this is going to look more like Neutron (which was very successful) and less like OpenFlow plugin (which was repeatedly and annoyingly blocked by having to have cross-project patches until we also moved the NSFs to the project).
On Thu, May 7, 2015 at 1:36 PM, Edward Warnicke <hagbard@...> wrote:
On 06/03/2015 09:48 PM, Colin Dixon wrote:
So, I agree with all of your points at the end (1-5+).Well, the fact that current cross-project synchronization between yangtools and controller are not visible is because we can coordinate and move quickly. That certainly does not mean they do not occur. Last time this was needed was ... https://git.opendaylight.org/gerrit/#/c/21220/ and https://git.opendaylight.org/gerrit/#/c/21223/.
As previously stated, binding-related classes in yangtools are much closer to MD-SAL classes in controller than they are to anything else in yangtools. Peering into what are candidate work items, I do not see this changing in at least one release. There is only one dependency (in flexible types), which is easily expressed as an inter-project dependency, with more than one consumer.
The move of models was the most important one, but the move of NSFs allowed them to be co-evolved -- there is no inventory manager in Lithium... I will also argue that a lot of the issues seen in OF-land run deeper than code location, but that's a different topic.
|1 - 3 of 3|