<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>And maybe this raises an interesting defininition mismatch in the conversation.<br>
<br>
There is archetectural stuff like, do we support 7 different web frameworks, or do we standardize on flask... python vs go.<br>
<br>
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.<br>
<br>
They are somewhat related at the op level when debugging is involved.<br>
<br>
But Im much more concerned with the latter archetecture getting attention then the former.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> James Bottomley<br>
<b>Sent:</b> Wednesday, July 20, 2016 12:42:27 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions); Clint Byrum<br>
<b>Subject:</b> Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, 2016-07-20 at 18:18 +0000, Fox, Kevin M wrote:<br>
> I wish it was so simple. Its not.<br>
> <br>
> There is a good coding practice:<br>
> "The code is done, not when there is nothing more to add, but nothing<br>
> more to remove"<br>
> <br>
> Some of the more mature projects are in this mode of thinking now.<br>
> (which is mostly good, really). They don't want to add features<br>
> unless they see it as a benefit to their users. This is the problem,<br>
> there is a disconnect between the view of Project X's users, and<br>
> greater view of OpenStack Users.<br>
> <br>
> Even accepting the smallest of patches to work towards the goal is<br>
> unacceptable to projects if they believe it is not a helpful feature<br>
> to their perceived user base, or helpful enough to them to justify<br>
> adding more code to their project. Or the feeling that "just push it<br>
> to a new project or a different one is better". This fractured view<br>
> of OpenStack users at the project level is preventing progress on<br>
> OpenStack as a whole.<br>
> <br>
> Only an overarching Architectural group with some power to define<br>
> what a user is, or the TC can address those sorts of issues.<br>
<br>
I'll concede this requirement if you can point out to me who this group<br>
is for the Linux Kernel. If you're tempted to say "Linus", it's most<br>
certainly not: while he does care about some architectural decisions,<br>
he emphatically avoids most of them, which leaves the subsystem<br>
maintainers (some equivalence to openstack projects/PTLs) doing this on<br>
a case by case basis.<br>
<br>
James<br>
<br>
> Thanks,<br>
> Kevin<br>
> ________________________________________<br>
> From: James Bottomley [James.Bottomley@HansenPartnership.com]<br>
> Sent: Wednesday, July 20, 2016 9:57 AM<br>
> To: OpenStack Development Mailing List (not for usage questions);<br>
> Clint Byrum<br>
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins<br>
> for all)<br>
> <br>
> On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:<br>
> > +1 to the finding of a middle ground.<br>
> <br>
> Thanks ... I have actually been an enterprise architect (I just keep<br>
> very quiet about it when talking Open Source).<br>
> <br>
> > The problem I've seen with your suggested OpenSource solution is<br>
> > the<br>
> > current social monetary system of OpenStack makes it extremely<br>
> > difficult.<br>
> > <br>
> > Each project currently prints its own currency. Reviews. It takes<br>
> > quite a few Reviews (time/effort) on a project to gain enough<br>
> > currency that you get payed attention to. And, one project doesn't<br>
> > honor another projects currency.<br>
> <br>
> OK, I accept your analogy, even though I would view currency as the<br>
> will to create and push patches.<br>
> <br>
> The problem you describe: getting the recipients to listen and accept<br>
> your patches, is also a common one. The first essential is simple<br>
> minimal patches because they're hard to reject.<br>
> <br>
> Once you've overcome the reject barrier, there's the indifference one<br>
> (no-one says no, but no-one says yes).<br>
> <br>
> Overcoming indifference involves partly knowing who to bother and<br>
> when<br>
> (In openstack, it's quite easy since you know who the core reviewers<br>
> are) and also building a consensus for the patch; usually this<br>
> involves<br>
> finding other people who need the feature and getting them to pipe up<br>
> (if you can't find other projects, then you can get potential users<br>
> to<br>
> do this) even better if they help you write the patches. Ideally,<br>
> you<br>
> build your consensus before you actually push the patch set. <br>
> Sometimes<br>
> building consensus involves looking beyond your particular need to a<br>
> bigger one that would satisfy you but also pulls other people in.<br>
> <br>
> > When these sorts of major cross project things need to be done<br>
> > though, you need to have folks with capital in many different<br>
> > projects and its very difficult to amass that much.<br>
> > <br>
> > There is no OpenStack level currency (other then being elected as a<br>
> > TC member) that gets one project to stop and take the time to<br>
> > carefully consider what someone is saying when bringing up cross<br>
> > project issues.<br>
> > <br>
> > Without some shared currency, then the problem becomes, the person<br>
> > invested in getting a solution, can propose and prototype and<br>
> > implement the feature all they want (often several times), but it<br>
> > never actually is accepted into the projects because a project:<br>
> > a) doesn't take the time to really understand the problem, feeling<br>
> > its trivial and just not accepting any reviews<br>
> > b) doesn't take the time to really understand the problem, so<br>
> > minimize it in their mind to a 'you should just use existing thing<br>
> > X...' or a heavy handily propose alternate solutions that really<br>
> > aren't solutions.<br>
> > c) they decide its better handled by another project and<br>
> > stall/block<br>
> > reviews, trying to push the implementation to go elsewhere. When<br>
> > multiple projects decide this, the ball just keeps getting bounced<br>
> > around without any solution for years.<br>
> > <br>
> > The status quo is not working here. The current governance<br>
> > structure<br>
> > doesn't support progress.<br>
> <br>
> What you'll find you've described above is a process that doesn't<br>
> support drive by coders at all and, by extension therefore, doesn't<br>
> welcome newcomers, which is a big problem, but one I thought<br>
> OpenStack<br>
> was tackling?<br>
> <br>
> The bounce problem is annoying but not insuperable. It mostly occurs<br>
> where there's overlap. Often the best method for coping is to field<br>
> the bounce: produce the patch for the other project. If it's smaller<br>
> and neater, perhaps the bounce was correct. If it's bigger and<br>
> uglier,<br>
> get the other project to say so and you now have a solid reason to go<br>
> back and say "we tried what you suggested and here's why it didn't<br>
> work". Morally, you're now on higher ground because incorrect<br>
> technical advice is a personal failure for whoever bounced you (make<br>
> sure to capitalise on it if they try another bounce).<br>
> <br>
> James<br>
> <br>
> <br>
> _____________________________________________________________________<br>
> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubs<br>
> cribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
> _____________________________________________________________________<br>
> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubs<br>
> cribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>