Open Stack

Excerpts from Ian Cordasco's message of 2016-06-21 11:12:40 -0500:
>  
> 
> -----Original Message-----
> From: Michael Krotscheck <krotscheck at gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Date: June 21, 2016 at 10:18:25
> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] Proposal: Architecture Working Group
> 
> > On Mon, Jun 20, 2016 at 10:59 AM Clint Byrum wrote:
> >  
> > >
> > > As you should be, and we all must be. It's not going to happen if we
> > > just dream it. That's kind of the point. Let's write down a design _for
> > > the group that writes down designs_.
> > >
> >  
> > If I had any confidence that this group would have a significant impact on
> > making OpenStack more consistent, easy to work on, and easier to build apps
> > against, I'd be happy to help out.
> >  
> > The only thing that would give me that confidence is if the WG charter had
> > a TC-enforced section of: "If you do not implement this *thing* within two
> > cycles, your project will get kicked out of OpenStack".
> 
> I don't think that will or *should* ever happen. The documents produced by this WG, to me, would be the set of best practices that should be aimed for, not mandatory. Forcing someone to refactor some complex piece of architecture in their project in < 1 year so the project can remain part of OpenStack seems like someone begging for horrible bugs and regressions in critical behaviour.
> 
> This is worse than saying "All projects should stop disabling hacking rules in two cycles or they'll stop receiving OpenStack Infra resources for testing." or "All projects need to write new versions of their API just to conform with the API WG."
> 

Just to be clear, I'm thinking more "This is how a thing should work",
not "best practices". The difference being that we'd write down something
like " message busses should look like X, Y, or Z based on factors a, b,
and/or c", and then we'd actually go fix or document the divergent cases
in OpenStack.

A best practices group would not actually fix anything IMO. It has to be
a group of action. Of course, we'll ask for help from any project teams
that are involved, and coordinate on things like release schedules so
we don't complicate short term plans. But I don't want this to just be a
standards body. I want this to be the group that gets the ball rolling,
and then helps it keep rolling.

There's no such thing as a perfect system, so we need to work toward
a process that produces _good_ results. Enforcement without merit will
just drive a wedge into that process.