Open Stack

On Thu, Jul 11, 2013 at 9:01 AM, Russell Bryant <rbryant at redhat.com> 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.  I must admit that my initial
> reaction is that I'm not comfortable with the direction this seems to be
> taking.
>

Same here, and I agree.


>
> 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.
>
> Some specific areas of concern to me:
>
> * In the introduction, the secondary issue identified is whether
> projects should be pluggable.  I believe this is TC territory.
>
> * Position statement 1, "plug-in model expected for projects".  I
> believe this is completely TC territory.
>

+1; not only TC territory, but it's a bogus assertion. Not everything has a
use case for pluggability... hence the statement made in the etherpad
"certain projects highly pluggable [...] while others have an opinion."


>
> * Position statement 2, "API extension model expected for plugin-ins".
> Again, I believe this is completely TC territory.
>

+1 for TC.


>
> * Position statement 3, "Tempest used as basis for OpenStack mark".  I
> think this is the wrong approach to take.  I think any position should
> assume a specific test suite.  It should identify *what* exactly should
> be covered in tests.  Using tempest is an implementation detail that
> comes after deciding *what*.  Do you want to verify just against core
> APIs?  All API extensions?  Whatever happens to be tested by tempest
> today doesn't seem like a good definition.
>

+1; start by considering the goals of tempest, not tempest itself.


>
> * In the "questions to ask" section, I disagree with many of things even
> being questions asked in this forum.  I won't go through all of them
> individually.
>
> I don't have answers here, but I wanted to raise my discomfort and see
> if anyone else felt similarly.
>

Thank you.


>
> Thanks,
>
> --
> Russell Bryant
>
> _______________________________________________
> 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/6e7c6823/attachment.html>