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.bottom...@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.bottom...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
