Open Stack

On 8/13/19 2:45 PM, Jeremy Freudberg wrote:
> Even though I agree the process this time around was comedy of errors
> (or worse), I don't think switching to numeric releases is
> particularly wise... for example, more than once someone has reported
> an issue with Sahara and stated that they are using <some number>
> version of Sahara. Turns out that <some number> is actually the
> version of the OSA playbooks being used. Let's not add another number
> to get confused about into the mix.

We also use version numbers for our downstream OpenStack product, and I 
believe others do as well. It's kind of nice to know that if someone is 
talking about a numerical version they mean downstream, whereas a letter 
means upstream.

Although I guess the other side of that is if upstream went to numbers 
downstream could just match those. It would be a little weird because 
we'd skip several major versions, but it could be done.

> 
> Anyway:
> - I think that now with you having pointed out everything that went
> wrong and having pointed us towards the simple steps that should be
> followed instead, we ought to give ourselves one more try to get the
> process correct for "V". We really should be able to get it right next
> time and there's something to be said for tradition.
> - I did not see in the document about how to determine the geographic
> region (its size etc or who should determine it). This is an
> opportunity for confusion sometimes leading to bitterness (and it was
> in the case of U -- whole China versus near Shanghai).
> 
> Just some thoughts.
> 
> P.S.: Single letter (like "U", "V") doesn't work when we wrap the
> alphabet (as has already been observed), but something like "U21",
> "V22", ... "A27" seems to work fine.

It doesn't solve the problem of tooling that assumes names will sort 
alphabetically though. I suppose we could go to ZA (all hail the mighty 
Za-Lord!*), ZB, etc., but that seems pretty hacky. I think we're 
ultimately going to have to make some changes to the tooling no matter 
what we decide now.

* any Dresden Files fans here? ;-)

> 
> On Tue, Aug 13, 2019 at 3:03 PM James E. Blair <corvus at inaugust.com> wrote:
>>
>> Rico Lin <rico.lin.guanyu at gmail.com> writes:
>>
>>> (Put my whatever hat on)
>>> Here's my suggestion, we can either make a patch to clarify the process
>>> step by step (no exception) or simply move everything out of
>>> https://governance.openstack.org/tc
>>> That actually leads to the current discussion here, to just use versions or
>>> not. Personally, I'm interested in improving the document and not that much
>>> interested in making only versions. I do like to see if we can use whatever
>>> alphabet we like so this version can be *cool*, and the next version can be
>>> *awesome*.  Isn't that sounds cool and awesome? :)
>>
>> I'm happy to help improve it if that's what folks want.  I already think
>> it says what you and several other people want it to say.  But I wrote
>> it, and so the fact that people keep reading it and coming away with
>> different understandings means I did a bad job.  So I'll need help to
>> figure out which parts I wasn't clear on.
>>
>> But I'm serious about the suggestion to scrap names altogether.  Every
>> time we have an issue with this, it's because people start making their
>> own judgments when the job of the coordinator is basically just to send
>> some emails.
>>
>> The process is 7 very clear steps.  Many of them were definitely not
>> followed this time.  We can try to make it more clear, but we have done
>> that before, and it still didn't prevent things from going wrong this
>> time.
>>
>> As a community, we just don't care enough to get it right, and getting
>> it wrong only produces bad feelings and wastes all our time.  I'm
>> looking forward to OpenStack Release 22.
>>
>> That sounds cool.  That's a big number.  Way bigger than like 1.x.
>>
>>> And like the idea
>>> Chris Dent propose to just use *U* or *V*, etc. to save us from having to
>>> have this discussion again(I'm actually the one to propose *U* in the list
>>> this time:) )
>>
>> That would solve a lot of problems, and create one new one in a few
>> years. :)
>>
>>> And if we're going to use any new naming system, I strongly suggest we
>>> should remove the *Geographic Region* constraint if we plan to have a poll.
>>> It's always easy to find conflict between what local people think about the
>>> name and what the entire community thinks about it.
>>
>> We will have a very long list if we do that.
>>
>> I'm not sure I agree with you about that problem though.  In practice,
>> deciding whether a river is within a state boundary is not that
>> contentious.  That's pretty much all that's ever been asked.
>>
>>> (Put my official hat on)
>>> And for the problem of *University* part:
>>> back in the proposal period, I find a way to add *University* back to the
>>> meet criteria list so hope people get to discuss whether or not it can be
>>> in the poll. And (regardless for the ongoing discussion about whether or
>>> not TC got any role to govern this process) I did turn to TCs and ask for
>>> the advice for the final answer (isn't that is the responsibility for TCs
>>> to guide?), so I guess we can say I'm the one to remove it out of the final
>>> list. Therefore I'm taking the responsibility to say I'm the one to omit
>>> *University*.
>>
>> Thanks.  I don't fault you personally for this, I think we got into this
>> situation because no one wanted to do it and so a confusing set of
>> people on the TC ended up performing various tasks ad-hoc.  That you
>> stepped up and took action and responsibility is commendable.  You have
>> my respect for that.
>>
>> I do think the conversation about University could have been more clear.
>> Specific yes/no answers and reasons would have been nice.  Instead of a
>> single decision about whether it was included, I received 3 decisions
>> with 4 rationales from several different people.  Either of the
>> following would have been perfectly fine outcomes:
>>
>> Me: Can has University, plz?
>> Coordinator: Violates criterion 4
>> Me: But Pike
>> Coordinator: Questionable, but process says be "generous"
>>               so, okay, it's in.
>> or
>> Coordinator: <Insert reason pike is invalid precedent>.  Sorry, it's
>>               still out.
>>
>> However, reasons around trademark or the suitability of English words
>> are not appropriate reasons to exclude a name.  Nor is "the TC didn't
>> like it".  There is only one reason to exclude a name, and that is that
>> it violates one of the 4 criteria.
>>
>> Of course it's fine to ask the TC, or anyone else for guidance.
>> However, it's clear from the IRC log that many members of the TC did not
>> appreciate what was being asked of them.  It would be okay to ask them
>> "Do you think this meets the criteria?"  But instead, a long discussion
>> about whether the names were *good choices* ensued.  That's not one of
>> the steps in the process.  In fact, it's the exact thing that the
>> process is supposed to avoid.  No matter what the members of the TC
>> thought about whether a name was a good idea, if it met the criteria it
>> should be in.
>>
>>> During the process, we omitted Ujenn, Uanjou, Ui, Uanliing, Ueihae, Ueishan
>>> from the meet criteria list because they're not the most popular spelling
>>> system in China. And we omitted Urumqi from the meet criteria list because
>>> of the potential political issue. Those are before I was an official. And
>>> we should consider them all during discuss about *University* here. I guess
>>> we should define more about in which stage should the official propose the
>>> final list of all names that meet criteria should all automatically be part
>>> of the final list.
>>
>> None of those should have been removed.  They, even more so than
>> University, clearly meet the criteria, and were only removed due to
>> personal preference.
>>
>> I want to be clear, there *is* a place for consideration of all of these
>> things.  That is step 3:
>>
>>    The marketing community may identify any names of particular concern
>>    from a marketing standpoint and discuss such issues publicly on the
>>    Marketing mailing list. The marketing community may produce a list of
>>    problematic items (with citations to the mailing list discussion of
>>    the rationale) to the election official. This information will be
>>    communicated during the election, but the names will not be removed
>>    from the poll.
>>
>> That is where we would identify things like "this name uses an unusual
>> romanization system" or "this name has political ramifications".  We
>> don't remove those names from the list, but we let the community know
>> about the issues, so that when people vote, they have all the
>> information.
>>
>> We trust our community to make good (or hilariously bad) decisions.
>>
>> That's what this all comes down to.  The process as written is supposed
>> to collect a lot of names, with a lot of information, and present them
>> to our community and let us all decide together.  That's what has been
>> lost.
>>
>> -Jim
>>
>