[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time
aschultz at redhat.com
Thu May 4 15:08:04 UTC 2017
On Thu, May 4, 2017 at 5:32 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> On Wed, 3 May 2017, Drew Fisher wrote:
>> This email is meant to be the ML discussion of a question I brought up
>> during the TC meeting on April 25th.; 
> Thanks for starting this Drew, I hope my mentioning it in my tc
> report email wasn't too much of a nag.
> I've added [tc] and [all] tags to the subject in case people are
> filtering. More within.
>> The TL;DR version is:
>> Reading the user survey , I see the same issues time and time again.
>> Pages 18-19 of the survey are especially common points.
>> Things move too fast, no LTS release, upgrades are terrifying for
>> anything that isn't N-1 -> N.
>> These come up time and time again
>> How is the TC working with the dev teams to address these critical issues?
> As I recall the "OpenStack-wide Goals"[a] are supposed to help address
> some of this sort of thing but it of course relies on people first
> proposing and detailing goals and then there actually being people
> to act on them. The first part was happening at[b] but it's not
> clear if that's the current way.
> Having people is the hard part. Given the current contribution
> model[c] that pretty much means enterprises ponying up the people do
> the work. If they don't do that then the work won't get done, and
> people won't buy the products they are supporting, I guess? Seems a
> sad state of affairs.
> There's also an issue where we seem to have decided that it is only
> appropriate to demand a very small number of goals per cycle
> (because each project already has too much on their plate, or too big
> a backlog, relative to resources). It might be that as the
> _Technical_ Committe is could be legitimate to make a larger demand.
> (Or it could be completely crazy.)
>> I asked this because on page 18 is this comment:
>> "Most large customers move slowly and thus are running older versions,
>> which are EOL upstream sometimes before they even deploy them."
> Can someone with more of the history give more detail on where the
> expectation arose that upstream ought to be responsible things like
> long term support? I had always understood that such features were
> part of the way in which the corporately avaialable products added
>> This is exactly what we're seeing with some of our customers and I
>> wanted to ask the TC about it.
> I know you're not speaking as the voice of your employer when making
> this message, so this is not directed at you, but from what I can
> tell Oracle's presense upstream (both reviews and commits) in Ocata
> and thus far in Pike has not been huge. Maybe that's something that
> needs to change to keep the customers happy? Or at all.
Probably because they are still on Kilo. Not sure how much they could
be contributing to the current when their customers are demanding that
something is rock solid which by now looks nothing like the current
upstream. I think this is part of the problem as the upstream can
tend to outpace anyone else in terms of features or anything else. I
think the the bigger question could be what's the benefit of
continuing to press forward and add yet more features when consumers
cannot keep up to consume these? Personally I think usability (and
some stability) sometimes tends to take a backseat to features in the
upstream which is unfortunate because it makes these problems worse.
> [a]: https://governance.openstack.org/tc/goals/index.html
> [b]: https://etherpad.openstack.org/p/community-goals
> [c]: There's talk that the current model will change from devs hired
> to do OpenStack development being the main engine of contribution to
> users of OpenStack, who happen to be devs, being the main engine. Do
> we know the slope on that trend?
>>  https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
> Chris Dent ┬──┬◡ﾉ(° -°ﾉ) https://anticdent.org/
> freenode: cdent tw: @anticdent
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev