[openstack-tc] Spider "What is Core" Discussion Continued - Monday 7/15 1-3pm Central
Dolph Mathews
dolph.mathews at gmail.com
Thu Jul 11 21:13:34 UTC 2013
On Thu, Jul 11, 2013 at 3:15 PM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Thu, 2013-07-11 at 10:01 -0400, Russell Bryant wrote:
> > On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com wrote:
> > > Board & TC Members,
> > >
> > >
> > >
> > > Alan and I have planned another 2 hour discussion session around the
> > > spider chart / what is core action plan. The goal for this meeting is
> > > to refine the 6 positions that we’ve articulated and identify
> additional
> > > ones needed (my gut says, 4+ more).
> > >
> > >
> > >
> > > If you have not been part of this meeting, we’ll explain what’s going
> on
> > > in the 1^st 15 minutes (and there’s information in the etherpad too).
> > > I’m working on a post about it too, but you’ll have to wait for that.
> >
> > > Background info:
> https://etherpad.openstack.org/Board-2013-SpiderDiscussion
> >
> > This is the first time I've seen this.
>
> Given that I'm on the board, it's not the first time I've seen it.
>
> With my "board hat" on, I buy into the high level goal here - encourage
> a marketplace of compatible OpenStack clouds by making the use of the
> trademark in association with a public cloud contingent on it passing
> some conformance tests.
>
> I've never really evolved my thinking much beyond that, though. For
> example, you could imagine taking this too far and eliminating any
> opportunity for OpenStack service providers to compete.
>
I don't perceive it as "competition" when it boils down to MyOpenStack vs
YourOpenStack because comparing API feature sets is like comparing apples
and oranges. End users don't win (see monty's example of not being able to
use CDN), and so OpenStack suffers. Service providers can always compete on
performance, reliability, cost, etc.
>
> I do think this is important to work through and am happy that someone
> is trying to make progress on it. Someone needs to.
>
> > I must admit that my initial
> > reaction is that I'm not comfortable with the direction this seems to be
> > taking.
> >
> > I understand the need to have a solid definition of what "core" means.
> > I also assume that the goal here is to eventually arrive at some set of
> > definitions and policies.
> >
> > However, some of the specific items discussed on this etherpad are
> > things that are in my opinion, in TC (or even project specific
> > governance) territory, and should be considered out of scope for any
> > policy coming from the board.
>
> Now with my "TC hat" on ...
>
> Yes, some of these positions do appear to be the kind of things that
> don't make sense for the board to be trying to enforce without the TC's
> buy-in. We could assume the request here is for the TC to consider
> whether it could imagine adopting these positions itself.
>
> There's a much deeper underlying assumption here that I'm beginning to
> wonder whether we really should be taking it for granted.
>
> The assumption is that the TC (and by extension, the project) actually
> wants to get involved with conformance testing as part of a trademark
> program at this point.
>
> Monty's proposal to make this conformance testing effort an official
> program is actually fairly enlightening - has a sufficiently large group
> of contributors formed around this effort such that we could say this is
> something the project clearly wants to take responsibility for at this
> point?
>
> Just because the board has strayed into a technical area doesn't mean
> the TC needs to automatically feel responsible for it. If the board
> decided to bring OpenStack APIs to some body for formal standardization,
> that too would be technical but I wouldn't be assuming the project would
> take responsibility for it.
>
> ...
>
> I think I'd like to see the board (and whoever else is interested in
> helping) make some progress on actually implementing a conformance
> program based on the status quo.
>
> If the board wants to say that projects without a "plug-in model" can't
> be core and won't be part of the conformance program, so be it. If the
> tempest project isn't interest in accepting the patches needed to make
> it suitable for conformance testing, so be it.
>
> Perhaps some of the policy decisions the board adopts results in
> projects making some technical changes (like adopting a plug-in model so
> they can be core) ... that smacks a little of extortion, but maybe we're
> ok with it because the project is still free to make its own decision.
>
> If the board goes too far by instituting a policy that is far away from
> the technical policy, it will put the efficacy of the conformance
> testing in jeopardy ... so there's a natural balance.
>
> ...
>
> The way we're approaching this now smacks of inevitable stalemate.
>
> I'm thinking of an approach whereby the TC unblocks those interested in
> making progress on conformance testing for a foundation trademark
> program:
>
> - the TC takes the stance that this is a board initiated effort and
> its policy is not endorsed by the TC
>
> - individual TC members may well contribute actively to the effort
>
> - the TC will later consider an application to bring the already
> well established conformance testing effort in as an official
> program
>
> ...
>
> Sorry, too long
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
--
-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130711/88d18a6b/attachment-0001.html>
More information about the OpenStack-TC
mailing list