Open Stack

On Wed, 2016-07-20 at 20:01 +0000, Fox, Kevin M wrote:
> I would argue Linus, yes. As he's constantly stepping up when a
> subsistem tries and breaks something for a user or creates a user
> facing mess and says, no, subsystem, no. breaking userspace is
> unacceptable, or, we're not adding support for an api we have to
> support forever thats very poorly designed.

Those are all vetos.  He doesn't compel one subsystem to accept the
patches of another, for instance.

>  Yes, he defers a lot to subsystem maintainers, as they have
> generally gotten the message of paying close attention to that kind
> of thing over time, and he hasn't had to speak up so much anymore.
> The rest really is best left up to the subsystems. But someone has to
> keep an eye on the big picture. The users of the whole thing. Users
> care about the linux kernel as a whole, and less so about any given
> subsystem.

He says "don't build this" (veto) he doesn't say "do build that"
(compulsion).  The problem I've heard a lot of people describing on
this thread is the latter: difficulty of getting one group to pay
attention to the needs of another.  Your "overarching Architectural
group with some power to define what a user is" is something like this.

The only power in Linux is the power to say "no".  The only way an
individual or a group builds acceptance for their own patches is on
their own.  Architectural decisions in this model are driven locally
not globally.

James


> Thanks,
> Kevin
> ________________________________________
> From: James Bottomley [James.Bottomley at HansenPartnership.com]
> Sent: Wednesday, July 20, 2016 12:42 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:unsu
> > bs
> > 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:unsu
> > bs
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>