Open Stack

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

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.

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?

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.

Mark.