[openstack-tc] Draft bylaws changes from DefCore bylaws subcommittee

Michael Still mikal at stillhq.com
Fri Mar 14 00:45:06 UTC 2014


This meeting was a pretty odd experience for me. I'm hoping I did an
ok job of representing the TC there, but its not clear to me that is
the case.

I do think there's a lack of consensus in the TC about if designated
sections are a good idea at all. I also think Josh sees our job as
just providing him with a list of things he's asked for without
discussing whether we think the request makes sense. I found his
behaviour in the meeting very unhelpful.

Michael

On Fri, Mar 14, 2014 at 9:47 AM, 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
>
> 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.
>
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc



-- 
Rackspace Australia



More information about the OpenStack-TC mailing list