Hi Ed: Is there also a similar page for concurrency model used by the controller project? I was investigating porting of net-virt host-tracker to controller (using SAL as the south bound interface),

Hi Ed - Thanks much for this. A question that came up that I wanted to reflect over on list -- which component of the model driven SAL is intended to do reconciliation in the case where you have

In the TSC call today I was asked to aggregate the information currently put out there about the Model Driven SAL and send it out to discuss to draw greater attention to it. The initial email (there

Resending with edits provided from folks like Chris and Dave. --Tom Email-based or Proxy-based Voting This proposal amends the existing TSC voting procedures that stipulate that voting by

* Rob Sherwood (rob.sherwood@...) wrote: Yes, I know. The point being that the bundle <-> repo connection is papered over by as build.

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.

* David Meyer (dmm@...) wrote: 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

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

I posted a question on the discuss list. However, I have a variant of the question for the TSC and would appreciate some clarification: What in our current/approved project lifecycle describes the

I just want to publicly say that I am not in favor of the creation of a third repository to house the merged code. For those of you who have been reading this list, that won't be news, but I wanted to

* David Meyer (dmm@...) wrote: Ah, got it...busy morning catching up w/ email ;)

* Kyle Forster (kyle.forster@...) wrote: Indeed, that's the idea! ;) <snip "we've got a repo for that"> Just a formality, but it actually doesn't. This would require: - project

Yes. This is why I sent the email outlining what the TSC charter allowed (there's a bit of a ordering problem here; see my next email). Briefly as I mentioned creation of a new project and/or

* David Meyer (dmm@...) wrote: What would we do with the outcome of this? I think it's only informational.

* David Meyer (dmm@...) wrote: I absolutely agree here. It is fundamental to the functioning of our community. That's right. The path forward for "DE plan in new repo" is a project proposal

* Kyle Forster (kyle.forster@...) wrote: This is a community effort. The whole premise of Opendaylight is founded on that tenant. We have project lifecycle and charter language to protect

Hi David & All, Maybe I missed something but I had understood the idea to begin with a new repository was proposed by David when the DE proposal was drafted, Colin was of the opinion to start with

David / all - I'd be happy to provide some stats on what a "tyranny of the majority committers" looks like from outside -- the asymmetric effort required to add interfaces to one project versus the

Kyle/all, <kyle.forster@...> wrote: In further considering the below, please find my comments in line. Please provide evidence to support these very serious accusations. IMO to begin with

I'm going to put the new repository question (as outlined by Kyle Forester in an email of Wed, May 15, 2013 at 7:04 AM) to a voice vote on the TSC call on Thursday. The options are: []