<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 6:47 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.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><div>On Thu, 2014-03-13 at 21:58 +0000, Mark McLoughlin wrote:<br>
> On Thu, 2014-03-13 at 17:07 +0000, Mark McLoughlin wrote:<br>
> > Hey<br>
> ><br>
> > I haven't been following this committee's progress and I can't speak to<br>
> > the rationale here, but a draft set of bylaws changes are being<br>
> > discussed by the committee:<br>
> ><br>
> > <a href="http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html" target="_blank">http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html</a><br>
> ><br>
> > This part is obviously going to be something of interest to the TC:<br>
> ><br>
> > (c) (i) The Technical Committee shall have the authority to<br>
> > determine the scope of the OpenStack Project subject to the<br>
> > procedures described below.<br>
> ><br>
> > (ii) The Technical Committee shall propose a process or<br>
> > procedure to determine the scope of the OpenStack Project.<br>
> > The Board of Directors may propose modifications to such<br>
> > process or procedure but such modifications must be<br>
> > approved by the Technical Committee. After the Technical<br>
> > Committee has approved the final process or procedure for<br>
> > determining the scope of the OpenStack Project and the<br>
> > Board of Directors has approved such process or procedure,<br>
> > the Board of Directors shall set the date on which such<br>
> > process or procedure becomes effective and the first such<br>
> > date shall be defined as the OSP New Definition Date.<br>
> > After the OSP New Definition Date, the Technical Committee<br>
> > may propose modifications to such process and procedure.<br>
> > The Board of Directors shall consider such modifications<br>
> > and may approve or disapprove them. If the Board of<br>
> > Directors approves such modifications, the modified process<br>
> > and procedure shall become the method for determining the<br>
> > scope of the OpenStack Project on the effective date set by<br>
> > the Board of Directors. The process or procedure shall be<br>
> > described in reasonable detail in the minutes of the Board<br>
> > of Directors which approved it. After such approval, the<br>
> > Secretary shall post such description to the Foundation’s<br>
> > website.<br>
> ><br>
> > Just on a call with the committee here and it seems the intent is to<br>
> > change the process around OpenStack capabilities associated with the<br>
> > trademark (i.e. what we now call "Core") as opposed to changing the<br>
> > process around adding new projects to the integrated release.<br>
> ><br>
> > However, right now I think we equate "the OpenStack Project" to the<br>
> > integrated release, so the actual wording does suggest a change to the<br>
> > TC's authority.<br>
><br>
> I had to drop from that call early to pick up my daughter from daycare,<br>
> but Mark Radcliffe followed up later with:<br>
><br>
> "I appreciate your comments at the Bylaws committee meeting. We don't<br>
> want to have the TC misunderstand the reasons for the bylaws change or<br>
> their consequences. These changes are focused solely on determining<br>
> how and when the trademark can be used. We want to ensure that the TC<br>
> has an active role in the decisions. Consequently, we will shift back<br>
> to the use of "core" for these procedures being set up. However, as<br>
> I noted, a number of members of DefCore Committee have expressed a<br>
> desire to use a word other than "core" for this concept so we may see<br>
> an additional change in the name."<br>
<br>
</div></div>Just surfacing other stuff as I find it ... I haven't listened to all of<br>
this, but:<br>
<br>
<a href="http://www.youtube.com/watch?v=eGiRrpDGzGU&t=72m30s" target="_blank">http://www.youtube.com/watch?v=eGiRrpDGzGU&t=72m30s</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">
Wow. Much anger, esp. from Josh.</div></div><div class="gmail_default" style="font-size:small"><br></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">
Basically quite a bit of angst from DefCore members about our response.<br>
<br>
It sounds like our response is being interpreted as an inability on our<br>
part to come to any consensus, which is not my read at all of our<br>
conversation on this. The "we are unlikely to reach a consensus"<br>
statement IMHO is about the length of time it would take to do this<br>
across all projects, rather than the difficulty in coming to agreement<br>
on it.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, I think they missed that point completely, as well as the fact that this is all coming up again in the middle of trying to put together a release candidate. Timing.</div>
</div><div><br></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">
My own intent on this was simply "what you're asking of us is hugely<br>
complex and we'd rather focus our time and effort on helping solidifying<br>
the API interop requirements rather than complex definitions of what<br>
code is required to be run".<br>
<br>
Anyone see this differently?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">My main issue at the point when we discussed this is the request was entirely unclear about what form "designation" needed to take. Knowing that would tell me just how much trouble the project would have keeping that list up to date over time. The examples in the etherpad linked below are extremely broad, which means it won't change that much from release to release but it also leaves the designation open for interpretation in ways that may not achieve what we want (nova's "API", being implemented as all extensions, will need to be defined in more detail, for example).</div>
</div><div><br></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">
Here's something else interesting:<br>
<br>
<a href="https://etherpad.openstack.org/p/openstack-designated-sections" target="_blank">https://etherpad.openstack.org/p/openstack-designated-sections</a><br>
<br>
Ignoring the snark in there, you can see the intent of designated<br>
sections here are that e.g. Nova is API, Conductor, Scheduler, Virt<br>
Driver and API extensions, and that only API and Conductor should be<br>
classified as designated/required. The "you must run API and Conductor"<br>
requirement would be a very high level, honor-based requirement rather<br>
than the detailed line-of-code by line-of-code type requirement we<br>
interpreted the request as.<br>
<br>
Ok, I'm done listening to Josh rant about the TC.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline"></div>I do think it's a good point that the PTLs who aren't on the TC now aren't being explicitly included in this discussion, but I'm not sure how to address that other than making sure they know when the topic is going to come up at a TC meeting so they can be present to contribute.<div class="gmail_default" style="font-size:small;display:inline">
If there is going to be a voice meeting, we should invite them to attend it if their project will be affected.</div><br></div><div><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">
I don't recognize a lot of the voices, but around 1:24 someone says designating APIs that can be used to substitute behavior would satisfy the requirement. If that's the case, then we should be able to put together a list of those places with a bit of research. It leaves open questions like whether certain features are included (cells?), but I guess those are covered by the test cases.</div>
<div class="gmail_default"><br></div></div><div><div class="gmail_default" style="font-size:small">Doug</div></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><div><br>
Mark.<br>
<br>
<br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org" target="_blank">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><br></div></div>