There have been plenty of cross project goals set forth from the TC and implemented by the various projects such as wsgi or python3. Those have been worked on by each of the projects in priority to some project specific goals by devs interested in bettering OpenStack. Why is it so hard to believe if the TC gave out a request for a grander user/ops supporting feature, that the community wouldn't step up? PTL's are supposed to be neutral to vendor specific issues and work for the betterment of the Project.
I don't buy the complexity argument either. Other non OpenStack projects are implementing similar functionality with far less complexity. I attribute a lot of that to difference in governence. Through governence we've made hard things much harder. They can't be fixed until the governence issues are fixed first I think. Thanks, Kevin ________________________________________ From: Jeremy Stanley [fu...@yuggoth.org] Sent: Tuesday, August 21, 2018 4:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction? On 2018-08-21 22:42:45 +0000 (+0000), Fox, Kevin M wrote: [...] > Yes, I realize shared storage was Cinders priority and Nova's now > way behind in implementing it. so it is kind of a priority to get > it done. Just using it as an example though in the bigger context. > > Having operators approach individual projects stating their needs, > and then having the individual projects fight it out for > priorities isn't a good plan. The priorities should be prioritized > at a higher level then projects so the operators/users needs can > be seen in a global light, not just filtered though each projects > views of things. > > Yes, some folks volunteer to work on the things that they want to > work on. Thats great. But some folks volunteer to work on > priorities to help users/operators in general. Getting clear, > unbiased priorities for them is really important. [...] I remain unconvinced that if someone (the TC, the OSF board, the now defunct product management nee hidden influencers working group) declared for example that secrets management was a higher priority than shared storage, that any significant number of people who could work on the latter would work on the former instead. The TC has enough trouble getting developers in different projects to cooperate on more than a couple of prioritized cross-project goals per cycle. The OSF board has repeatedly shown its members are rarely in the positions within member companies that they have any influence over what upstream features/projects those companies work on. The product management working group thought they had that influence over the companies in which they worked, but were similarly unable to find developers who could make progress toward their identified goals. OpenStack is an extremely complex (arguably too complex) combination of software, for which there are necessarily people with very strong understanding of very specific pieces and at best a loose understanding of the whole. In contrast, there are few people who have both the background and interest (much less leeway from their employers in the case of paid contributors) to work on any random feature of any random project and be quickly effective at it. If you're familiar with, say, Linux kernel development, you see very much the same sort of specialization with developers who are familiar with specific kernel subsystems and vanishingly few who can efficiently (that is to say without investing lots of time to come up to speed) implement novel features in multiple unrelated subsystems. We'll all continue to work on get better at this, but hard things are... well... hard. -- Jeremy Stanley __________________________________________________________________________ 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