<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 11:58 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
On Sep 29, 2014, at 5:51 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
<br>
> Boris Pavlovic wrote:<br>
>> it goes without saying that working on cross-project stuff in OpenStack<br>
>> is quite hard task.<br>
>><br>
>> Because it's always hard to align something between a lot of people from<br>
>> different project. And when topic start being too "HOT"  the discussion<br>
>> goes in wrong direction and attempt to do cross project change fails, as<br>
>> a result maybe not *ideal* but *good enough* change in OpenStack will be<br>
>> abandoned.<br>
>><br>
>> The another issue that we have are "specs". Projects are asking to make<br>
>> spec for change in their project, and in case of cross project stuff you<br>
>> need to make N similar specs (for every project). That is really hard to<br>
>> manage, and as a result you have N different specs that are describing<br>
>> the similar stuff.<br>
>><br>
>> To make this process more formal, clear and simple, let's reuse process<br>
>> of "specs" but do it in one repo /openstack/cross-project-specs.<br>
>><br>
>> It means that every cross project topic: Unification of python clients,<br>
>> Unification of logging, profiling, debugging api, bunch of others will<br>
>> be discussed in one single place..<br>
><br>
> I think it's a good idea, as long as we truly limit it to cross-project<br>
> specs, that is, to concepts that may apply to every project. The<br>
> examples you mention are good ones. As a counterexample, if we have to<br>
> sketch a plan to solve communication between Nova and Neutron, I don't<br>
> think it would belong to that repository (it should live in whatever<br>
> project would have the most work to do).<br>
><br>
>> Process description of cross-project-specs:<br>
>><br>
>>  * PTL - person that mange core team members list and puts workflow +1<br>
>>    on accepted specs<br>
>>  * Every project have 1 core position (stackforge projects are included)<br>
>>  * Cores are chosen by project team, they task is to advocate project<br>
>>    team opinion<br>
>>  * No more veto, and -2 votes<br>
>>  * If > 75% cores +1 spec it's accepted. It means that all project have<br>
>>    to accept this change.<br>
>>  * Accepted specs gret high priority blueprints in all projects<br>
><br>
> So I'm not sure you can force "all projects to accept the change".<br>
> Ideally, projects should see the benefits of alignment and adopt the<br>
> common spec. In our recent discussions we are also going towards more<br>
> freedom to projects, rather than less : imposing common specs to<br>
> stackforge projects sounds like a step backwards there.<br>
><br>
> Finally, I see some overlap with Oslo, which generally ends up<br>
> implementing most of the "common policy" into libraries it encourages<br>
> usage of. Therefore I'm not sure having a "cross-project" PTL makes<br>
> sense, as he would be stuck between the Oslo PTL and the Technical<br>
> Committee.<br>
<br>
</div></div>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.<br>
<br>
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.<br>
<br>
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?<br></blockquote><div><br></div><div>Here is a governance patch to propose a openstack-specs repo: <a href="https://review.openstack.org/125509">https://review.openstack.org/125509</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
><br>
>> With such simple rules we will simplify cross project work:<br>
>><br>
>> 1) Fair rules for all projects, as every project has 1 core that has 1<br>
>> vote.<br>
><br>
> A "project" is hardly a metric for fairness. Some projects are 50 times<br>
> bigger than others. What is a "project" in your mind ? A code repository<br>
> ? Or more like a program (a collection of code repositories being worked<br>
> on by the same team ?)<br>
><br>
> So in summary, yes we need a place to discuss truly cross-project specs,<br>
> but I think it can't force decisions to all projects (especially<br>
> stackforge ones), and it can live within a larger-scope Oslo effort<br>
> and/or the Technical Committee.<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>