Also, IIRC, Chris and Ed were going to have feedback on the 2nd section of the document.  Is it possible to get example text or general thoughts about it posted before the call so we can try to have a more focused conversation?  I realize we only have a few hours, but even a few minutes of time to read the text might be useful.

- Rob

.

On Thu, Apr 25, 2013 at 7:22 AM, David Meyer <dmm@...> wrote:

This is the first topic for our call today. We have to complete our feedback for the board this week.

--dmm

On Thu, Apr 25, 2013 at 3:57 AM, Thomas Nadeau <tnadeau@...> wrote:

This is definitely worth discussing on the next call.  

--Tom

From: Rob Sherwood <rob.sherwood@...>
Date: Wednesday, April 24, 2013 4:56 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Feedback on singularity text for TSC Policy document

Hi TSC folks and all,

I just wanted to start this thread to try to get some feedback before the TSC meeting.  I took the action to suggest updated text for the Singularity part of the draft TSC policies document.

The originally proposed text says:

------

The following relate the projects initiated by the TSC and the artifacts created therein.

·      Singularity:  To the extent possible, there should be  no overlap between the goals of the mature projects and artifacts created by them

·      Cohesiveness:  The artifacts created within each mature project should connect appropriately to other mature/core projects to form a cohesive system.  (It is understood that this will not apply to artifacts that are  stand-alone by design)

-------

Before I settle on the updated text, I wanted to suggest the following policy and get feedback on it.

In my mind, given not only do we have some overlap in the controller space, but as more network virtualization projects start to land (e.g., Dove from IBM, the proposed contribution from NEC) we will have even more overlapping code in the near future.  So, in other words we will likely need some sort of staged strategy for resolving the overlap and incentives for doing so in a timely manner.

So specifically my proposal is:

1) For bootstrap and incubation stages, allow overlapping code bases.

2) In order to get to the 'mature' state, there has to be an agreed upon plan (by all affected projects) for how to merge all of the code into a single code base.

3) In order to get into the 'core' state, the code has to be successfully merged (read: there can only be one core project of any one piece of functionality)

Does this make sense?  I think this tracks both with people's expectations (in that we should be working to remove overlap) as well as the current reality (we have a bunch of overlapping code without a plan or incentive for how quickly we need to resolve the overlap).  By using the 'mature' state as a "do you at least have a plan" state and the 'core' state as "did you successfully execute that plan" I feel like there are reasonable steps towards incremental progress in place.

I'm hoping this is the best of both worlds, but I'm open to feedback,

- Rob

.

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc