Open Stack

And maybe this raises an interesting defininition mismatch in the conversation.

There is archetectural stuff like, do we support 7 different web frameworks, or do we standardize on flask... python vs go.

Theres also the architectural stuff at the, what interactive surface do you expose to users/operators. How consistant is it. Does it have all the features, no matter where they are implemented to do work.

They are somewhat related at the op level when debugging is involved.

But Im much more concerned with the latter archetecture getting attention then the former.

Thanks,
Kevin

________________________________
From: James Bottomley
Sent: Wednesday, July 20, 2016 12:42:27 PM
To: OpenStack Development Mailing List (not for usage questions); Clint Byrum
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On Wed, 2016-07-20 at 18:18 +0000, Fox, Kevin M wrote:
> I wish it was so simple. Its not.
>
> There is a good coding practice:
> "The code is done, not when there is nothing more to add, but nothing
> more to remove"
>
> Some of the more mature projects are in this mode of thinking now.
> (which is mostly good, really). They don't want to add features
> unless they see it as a benefit to their users. This is the problem,
> there is a disconnect between the view of Project X's users, and
> greater view of OpenStack Users.
>
> Even accepting the smallest of patches to work towards the goal is
> unacceptable to projects if they believe it is not a helpful feature
> to their perceived user base, or helpful enough to them to justify
> adding more code to their project. Or the feeling that "just push it
> to a new project or a different one is better". This fractured view
> of OpenStack users at the project level is preventing progress on
> OpenStack as a whole.
>
> Only an overarching Architectural group with some power to define
> what a user is, or the TC can address those sorts of issues.

I'll concede this requirement if you can point out to me who this group
is for the Linux Kernel.  If you're tempted to say "Linus", it's most
certainly not: while he does care about some architectural decisions,
he emphatically avoids most of them, which leaves the subsystem
maintainers (some equivalence to openstack projects/PTLs) doing this on
a case by case basis.

James

> Thanks,
> Kevin
> ________________________________________
> From: James Bottomley [James.Bottomley at HansenPartnership.com]
> Sent: Wednesday, July 20, 2016 9:57 AM
> To: OpenStack Development Mailing List (not for usage questions);
> Clint Byrum
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
>
> On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:
> > +1 to the finding of a middle ground.
>
> Thanks ... I have actually been an enterprise architect (I just keep
> very quiet about it when talking Open Source).
>
> > The problem I've seen with your suggested OpenSource solution is
> > the
> > current social monetary system of OpenStack makes it extremely
> > difficult.
> >
> > Each project currently prints its own currency. Reviews. It takes
> > quite a few Reviews (time/effort) on a project to gain enough
> > currency that you get payed attention to. And, one project doesn't
> > honor another projects currency.
>
> OK, I accept your analogy, even though I would view currency as the
> will to create and push patches.
>
> The problem you describe: getting the recipients to listen and accept
> your patches, is also a common one.  The first essential is simple
> minimal patches because they're hard to reject.
>
> Once you've overcome the reject barrier, there's the indifference one
> (no-one says no, but no-one says yes).
>
> Overcoming indifference involves partly knowing who to bother and
> when
> (In openstack, it's quite easy since you know who the core reviewers
> are) and also building a consensus for the patch; usually this
> involves
> finding other people who need the feature and getting them to pipe up
> (if you can't find other projects, then you can get potential users
> to
> do this) even better if they help you write the patches.  Ideally,
> you
> build your consensus before you actually push the patch set.
>  Sometimes
> building consensus involves looking beyond your particular need to a
> bigger one that would satisfy you but also pulls other people in.
>
> > When these sorts of major cross project things need to be done
> > though, you need to have folks with capital in many different
> > projects and its very difficult to amass that much.
> >
> > There is no OpenStack level currency (other then being elected as a
> > TC member) that gets one project to stop and take the time to
> > carefully consider what someone is saying when bringing up cross
> > project issues.
> >
> > Without some shared currency, then the problem becomes, the person
> > invested in getting a solution, can propose and prototype and
> > implement the feature all they want (often several times), but it
> > never actually is accepted into the projects because a project:
> >  a) doesn't take the time to really understand the problem, feeling
> > its trivial and just not accepting any reviews
> >  b) doesn't take the time to really understand the problem, so
> > minimize it in their mind to a 'you should just use existing thing
> > X...' or a heavy handily propose alternate solutions that really
> > aren't solutions.
> >  c) they decide its better handled by another project and
> > stall/block
> > reviews, trying to push the implementation to go elsewhere. When
> > multiple projects decide this, the ball just keeps getting bounced
> > around without any solution for years.
> >
> > The status quo is not working here. The current governance
> > structure
> > doesn't support progress.
>
> What you'll find you've described above is a process that doesn't
> support drive by coders at all and, by extension therefore, doesn't
> welcome newcomers, which is a big problem, but one I thought
> OpenStack
> was tackling?
>
> The bounce problem is annoying but not insuperable.  It mostly occurs
> where there's overlap.  Often the best method for coping is to field
> the bounce: produce the patch for the other project.  If it's smaller
> and neater, perhaps the bounce was correct.  If it's bigger and
> uglier,
> get the other project to say so and you now have a solid reason to go
> back and say "we tried what you suggested and here's why it didn't
> work".  Morally, you're now on higher ground because incorrect
> technical advice is a personal failure for whoever bounced you (make
> sure to capitalise on it if they try another bounce).
>
> James
>
>
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/60d6a34c/attachment.html>