Open Stack

On 05/04/2017 11:08 AM, Alex Schultz wrote:
> 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.; [1]
>>
>>
>> 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 [2], 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
>> value?
>>
>>> 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.

The general statement of "people care more about features than
usability/stability" gets thrown around a lot. And gets lots of head
nodding. But rarely comes with specifics.

Can we be specific about what feature work is outpacing the consumers
that don't help with usability/stability?

	-Sean

-- 
Sean Dague
http://dague.net