On Thu, Jun 23, 2016 at 9:49 AM, Colin Dixon <[email protected]> wrote:
> 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. > +1 yes, that's the point I am trying to make in my response above. > > --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 >> >> > -- Thanks Anil
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
