Open Stack

Excerpts from John Dickinson's message of 2016-10-03 14:26:00 -0700:
> 
> On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
> >
> > I think that's the balance we want to
> > have: listen to input, collect information, then clearly set the
> > direction without over-prescribing the implementation.
> 
> In light of this statement, would you reevaluate previous decisions you've made regarding implementation details? You've criticized OpenStack projects for not using certain code, you've advocated for openstack-wide goals which are all about implementation[1], and you voted against Swift and other projects using Golang for an internal process[2]. Each of these are quite prescriptive with regards to the implementation. Would you change your vote on any of these decisions if you are reelected?
> 
> [1] https://review.openstack.org/#/c/349068/
> [2] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html

I said "without *over-prescribing*", not "without prescribing at
all". I generally don't care how the goal is achieved, as long as
it is. That's why the goals framework focuses on describing end-states,
and not procedures or "specs".

Yes, sometimes I will advocate for goals that involve implementation
details of projects.  Probably a lot of the time, actually, since
most of the goals we've discussed so far are related to doing things
consistently (if you're interested in the other goals being discussed,
there's an etherpad [3]). I want projects to use common tools and
implementation patterns as much as possible, because doing so
benefits our users, makes life easier for our contributors, and
enables cross-project efforts like infrastructure, documentation,
and release management. Common tools and patterns also contribute
to our sense of being one community that is working on one over-arching
project.

Taking the two specific goals discussed over the past few months:

The Python 3 goal is about running tests under Python 3 as well as
Python 3. I don't care what order or process projects follow to get
their tests running under Python 3. I do want them to do it, and I
do want them to get *all* of the tests running.

The Oslo cleanup goal is related to dealing with unsupported code
lingering in projects.  Projects should either remove unsupported
code in favor of supported code, or declare that they will support
the "forked" modules themselves by moving them out of a common
directory that implies they are supported by the Oslo team. Either
way we convert to using supported code and satisfy the goal.

Regarding Golang, I tried to explain my position to you at OpenStack
Days East a few weeks ago, but apparently I wasn't as clear as I
thought.  I have to look beyond the Swift team's immediate needs
and consider our entire community.  With that in mind, I did not
reject the use of Golang outright or permanently. I voted against
the Swift team's current request to be the first team to use it,
and in effect establish the standards for its use, based on the
team's continual resistance to adopting community standards.  Anyone
interested in the full statement I made at the time should read the
pastebin [4] as well as the meeting logs.

When the two of us talked about this in person, I tried to express
to you that I will reconsider my vote when the Swift team demonstrates
that it has revised its stance and begins participating in community
standards to the extent that I believe they would be good stewards
of the infrastructure needed to allow teams *besides themselves*
to use Golang.  If I am not mistaken, recently the team has done
some work to start incorporating reno, and I count that as a good
step.

If another team demonstrates a need to use a language other than
Python, I will consider their request separately and on its own
merits, regardless of the language.

Doug

[3] https://etherpad.openstack.org/p/community-goals
[4] http://paste.openstack.org/show/545744/