On Sep 29, 2014, at 5:51 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Boris Pavlovic wrote: >> it goes without saying that working on cross-project stuff in OpenStack >> is quite hard task. >> >> Because it's always hard to align something between a lot of people from >> different project. And when topic start being too "HOT" the discussion >> goes in wrong direction and attempt to do cross project change fails, as >> a result maybe not *ideal* but *good enough* change in OpenStack will be >> abandoned. >> >> The another issue that we have are "specs". Projects are asking to make >> spec for change in their project, and in case of cross project stuff you >> need to make N similar specs (for every project). That is really hard to >> manage, and as a result you have N different specs that are describing >> the similar stuff. >> >> To make this process more formal, clear and simple, let's reuse process >> of "specs" but do it in one repo /openstack/cross-project-specs. >> >> It means that every cross project topic: Unification of python clients, >> Unification of logging, profiling, debugging api, bunch of others will >> be discussed in one single place.. > > I think it's a good idea, as long as we truly limit it to cross-project > specs, that is, to concepts that may apply to every project. The > examples you mention are good ones. As a counterexample, if we have to > sketch a plan to solve communication between Nova and Neutron, I don't > think it would belong to that repository (it should live in whatever > project would have the most work to do). > >> Process description of cross-project-specs: >> >> * PTL - person that mange core team members list and puts workflow +1 >> on accepted specs >> * Every project have 1 core position (stackforge projects are included) >> * Cores are chosen by project team, they task is to advocate project >> team opinion >> * No more veto, and -2 votes >> * If > 75% cores +1 spec it's accepted. It means that all project have >> to accept this change. >> * Accepted specs gret high priority blueprints in all projects > > So I'm not sure you can force "all projects to accept the change". > Ideally, projects should see the benefits of alignment and adopt the > common spec. In our recent discussions we are also going towards more > freedom to projects, rather than less : imposing common specs to > stackforge projects sounds like a step backwards there. > > Finally, I see some overlap with Oslo, which generally ends up > implementing most of the "common policy" into libraries it encourages > usage of. Therefore I'm not sure having a "cross-project" PTL makes > sense, as he would be stuck between the Oslo PTL and the Technical > Committee. There is some overlap with Oslo, and we would want to be involved in the discussions — especially if the plan includes any code to land in an Oslo library. I have so far been resisting the idea that oslo-specs is the best home for this, mostly because I didn’t want us to assume everything related to cross-project work is also related to Oslo work. That said, our approval process looks for consensus among all of the participants on the review, in addition to Oslo cores, so we can use oslo-specs and continue incorporating the +1/-1 votes from everyone. One of the key challenges we’ve had is signaling buy-in for cross-project work so having some sort of broader review process would be good, especially to help ensure that all interested parties have a chance to participate in the review. OTOH, a special repo with different voting permission settings also makes sense. I don’t have any good suggestions for who would decide when the voting on a proposal had reached consensus, or what to do if no consensus emerges. Having the TC manage that seems logical, but impractical. Maybe a person designated by the TC would oversee it? > >> With such simple rules we will simplify cross project work: >> >> 1) Fair rules for all projects, as every project has 1 core that has 1 >> vote. > > A "project" is hardly a metric for fairness. Some projects are 50 times > bigger than others. What is a "project" in your mind ? A code repository > ? Or more like a program (a collection of code repositories being worked > on by the same team ?) > > So in summary, yes we need a place to discuss truly cross-project specs, > but I think it can't force decisions to all projects (especially > stackforge ones), and it can live within a larger-scope Oslo effort > and/or the Technical Committee. > > -- > Thierry Carrez (ttx) > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
