Open Stack

Michael,

After listening to that recording, I have to say that this whole thing
became far more confrontational than I expected so thank you for taking it
on the job of being our representative. I thought you did a good job.

In particular, I appreciate you pointing out that some of us don't have
the whole history of this discussion, and that lack of context is leading
to some of the questions that have been raised. It was nice to see Josh
recognize that the words they use sometimes lead to confusion, too.

Doug



On Thu, Mar 13, 2014 at 8:45 PM, Michael Still <mikal at stillhq.com> wrote:

> 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
>
> _______________________________________________
> 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/92de36f4/attachment-0001.html>