Open Stack

On Thu, Mar 13, 2014 at 6:47 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2014-03-13 at 21:58 +0000, Mark McLoughlin wrote:
> > On Thu, 2014-03-13 at 17:07 +0000, Mark McLoughlin wrote:
> > > Hey
> > >
> > > I haven't been following this committee's progress and I can't speak to
> > > the rationale here, but a draft set of bylaws changes are being
> > > discussed by the committee:
> > >
> > >
> http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html
> > >
> > > This part is obviously going to be something of interest to the TC:
> > >
> > >     (c) (i)  The Technical Committee shall have the authority to
> > >              determine the scope of the OpenStack Project subject to
> the
> > >              procedures described below.
> > >
> > >        (ii)  The Technical Committee shall propose a process or
> > >              procedure to determine the scope of the OpenStack Project.
> > >              The Board of Directors may propose modifications to such
> > >              process or procedure but such modifications must be
> > >              approved by the Technical Committee. After the Technical
> > >              Committee has approved the final process or procedure for
> > >              determining the scope of the OpenStack Project and the
> > >              Board of Directors has approved such process or procedure,
> > >              the Board of Directors shall set the date on which such
> > >              process or procedure becomes effective and the first such
> > >              date shall be defined as the OSP New Definition Date.
> > >              After the OSP New Definition Date, the Technical Committee
> > >              may propose modifications to such process and procedure.
> > >              The Board of Directors shall consider such modifications
> > >              and may approve or disapprove them. If the Board of
> > >              Directors approves such modifications, the modified
> process
> > >              and procedure shall become the method for determining the
> > >              scope of the OpenStack Project on the effective date set
> by
> > >              the Board of Directors.  The process or procedure shall be
> > >              described in reasonable detail in the minutes of the Board
> > >              of Directors which approved it. After such approval, the
> > >              Secretary shall post such description to the Foundation's
> > >              website.
> > >
> > > Just on a call with the committee here and it seems the intent is to
> > > change the process around OpenStack capabilities associated with the
> > > trademark (i.e. what we now call "Core") as opposed to changing the
> > > process around adding new projects to the integrated release.
> > >
> > > However, right now I think we equate "the OpenStack Project" to the
> > > integrated release, so the actual wording does suggest a change to the
> > > TC's authority.
> >
> > I had to drop from that call early to pick up my daughter from daycare,
> > but Mark Radcliffe followed up later with:
> >
> >   "I appreciate your comments at the Bylaws committee meeting.  We don't
> >   want to have the TC misunderstand the reasons for the bylaws change or
> >   their consequences. These changes are focused solely on determining
> >   how and when the trademark can be used.  We want to ensure that the TC
> >   has an active role in the decisions.  Consequently, we will shift back
> >   to the use of "core" for these procedures being set up.   However, as
> >   I noted,  a number of members of DefCore Committee have expressed a
> >   desire to use a word other than "core" for this concept so we may see
> >   an additional change in the name."
>
> Just surfacing other stuff as I find it ... I haven't listened to all of
> this, but:
>
>   http://www.youtube.com/watch?v=eGiRrpDGzGU&t=72m30s


Wow. Much anger, esp. from Josh.

Basically quite a bit of angst from DefCore members about our response.
>
> It sounds like our response is being interpreted as an inability on our
> part to come to any consensus, which is not my read at all of our
> conversation on this. The "we are unlikely to reach a consensus"
> statement IMHO is about the length of time it would take to do this
> across all projects, rather than the difficulty in coming to agreement
> on it.
>

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.

My own intent on this was simply "what you're asking of us is hugely
> complex and we'd rather focus our time and effort on helping solidifying
> the API interop requirements rather than complex definitions of what
> code is required to be run".
>
> Anyone see this differently?
>

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).

Here's something else interesting:
>
>   https://etherpad.openstack.org/p/openstack-designated-sections
>
> Ignoring the snark in there, you can see the intent of designated
> sections here are that e.g. Nova is API, Conductor, Scheduler, Virt
> Driver and API extensions, and that only API and Conductor should be
> classified as designated/required. The "you must run API and Conductor"
> requirement would be a very high level, honor-based requirement rather
> than the detailed line-of-code by line-of-code type requirement we
> interpreted the request as.
>
> Ok, I'm done listening to Josh rant about the TC.
>


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.
 If there is going to be a voice meeting, we should invite them to attend
it if their project will be affected.


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.

Doug


>
> Mark.
>
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140314/502cc9ac/attachment.html>