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/ __________________________________________________________________________ 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
