Specifically answering Vratko's questions 1.) The centrality of role is intentionally left up to interpretation and there is no other document. 2.) I think your incomplete list of candidate projects seems reasonable to me. 3.) The overlap specified in the singularity principle is actually the "overlap between goals of core projects and the artifacts created by them" [2], which I'd interpret to mean that a core project can't overlap with itself, but others might interpret the artifacts part to mean that even within a core project it shouldn't have overlapping artifacts and that might be a good thing.
More generally, I'm curious if the full text of the singularity principle, which states: > Singularity: To the extent possible, there should be no overlap between > the goals of the core projects and artifacts created by them > Gives enough room for interpretation that it's not as damaging as one might think. In particular, the "To the extent possible," section seems to offer some flexibility and may render the principle more of a guideline than an ironclad, unbreakable rule. --Colin [2] https://www.opendaylight.org/tsc-policy On Fri, Jun 17, 2016 at 8:25 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) <[email protected]> wrote: > First of all, is there a definition of what Core project is, > > more detailed than [0]? > > "Statement of centrality of role" sounds like > > it may be alluding to some other document. > > > > Here is an incomplete list of project I expect > > to become good candidates for core projects: > > odlparent, yangtools, mdsal, integration/distribution, > > releng/autorelease, releng/builder, integration/test. > > > > Example of artifacts overlap: openflowplugin-he vs openflowplugin-li. > > Example of evolution without overlap: from odl to new yang parser. > > Example of winner becoming de facto core: MD-SAL over AD-SAL. > > > > I can see benefit of keeping Singularity clause in. > > What is missing is a process how to demote from Core > > once an alternative functionality appears. > > > > And perhaps lines such as > > "The TSC members are the project leads from the Core projects." [1] > > should be reformulated. > > > > Vratko. > > > > [0] https://www.opendaylight.org/project-lifecycle-releases#ProjectTypes > > [1] https://www.opendaylight.org/tsc-charter > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Anil Vishnoi > *Sent:* 16 June, 2016 23:44 > *To:* Edward Warnicke <[email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* Re: [OpenDaylight Discuss] Asking the Board to Remove the > Singularity Principle > > > > comments inline .. > > > > On Thu, Jun 16, 2016 at 11:09 AM, Edward Warnicke <[email protected]> > wrote: > > Anil today brought up the issue of the Singularity Principle in the TSC > Policy > > in todays TSC: > > > > https://www.opendaylight.org/tsc-policy > > > > The TSC Policy contains a statement: > > > > "Singularity: To the extent possible, there should be no overlap between > the goals of the core projects and artifacts created by them" > > > > There were questions raised as to the impact this had as projects because > core on other projects, and I was #actioned to start an email conversation > on the topic. > > > > To me, the singularity clause is troubling because it implies that once a > project reaches core, nobody can compete with things that are within its > scope, effectively innovation is shut off. In my mind, part of being a > truly open source project is being an open innovation regime, and that > implies that we do not anoint 'the one true winner' in a particular area, > but allow that to emerge based up quality of the work a project produces > and its adoption. In the presence of the Singularity clause, core > promotions feel to much like > > > > picking winners-for-all-time via a political process, rather than allowing > winners to emerge via technical merit. > > So I would propose that the TSC petition the board to strike the > Singularity Clause from the TSC policy. > > > > > > I agree with the problem ( > > > > picking winners-for-all-time > > ) but i have a strong objection to the solution proposed in the above > line (I would be happy to reduce the strength of my objection as i read > more valid argument in favor of the above proposal :) ). I believe the > existing text of Singularity clause is very appropriate, because in my > interpretation it says that we should not open the "core projects" gate for > the projects with overlapping scope until and unless we see a real value to > have them as a core project. > > > > In my understanding (I may be wrong), main intention of having the project > life cycle is to provide a stable platform to the downstream projects on > which they can build their innovative applications with certain level of > confidence. And to deliver such a platform i believe we need to keep the > criterias high (that does not necessarily mean saying "no" to the > projects). I believe organizations that are consuming ODL has the same > expectation as well. As a ODL project, we need to make sure that projects > should feel free to innovate in the ecosystem, but we would also assure > that we give a stable platform to the downstream project and TSC plays a > critical role here to keep that balance. Allowing project with overlapping > scope under OpenDaylight umbrella provides freedom to the project to > innovate and project life cycle + singularity clause assures that > OpenDaylight deliver the stable platform to their downstream consumer. > > > > Rather than striking out the singularity clause, I would suggest that we > should have a clause/law/guideline on how an existing core project can be > replaced with the project with superior technical merit. Will that solve > all the possible scenarios? Probably not, but the current singularity > clause does not stop TSC from allowing those project to become core project > if having them has a real value to ODL consumers. > > > > > > > > I am curious to hear the thoughts of others on the subject. > > > > Ed > > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss > > > > > > -- > > Thanks > > Anil > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss > >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
