Re: [openstack-dev] [tc][cross-project-work] What about adding cross-project-spec repo?
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
Re: [openstack-dev] [tc][cross-project-work] What about adding cross-project-spec repo?
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. 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
Re: [openstack-dev] [tc][cross-project-work] What about adding cross-project-spec repo?
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
