On Mon, Sep 29, 2014 at 11:58 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> > 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? > Here is a governance patch to propose a openstack-specs repo: https://review.openstack.org/125509 > > > > >> 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev