[openstack-dev] [tc][all] Missing answers on Pike release goals

John Dickinson me at not.mn
Tue May 23 16:12:29 UTC 2017

On 23 May 2017, at 8:05, Doug Hellmann wrote:

> Excerpts from Sean McGinnis's message of 2017-05-23 08:58:08 -0500:
>>>> - Is it that the reporting process is too heavy ? (requiring answers
>>>> from projects that are obviously unaffected)
>>> I've thought about this, OSC was unaffected by one of the goals but
>>> not the other, so I can't really hide in this bucket.  It really is
>>> not that hard to put up a review saying "not me".
>>>> - Is it that people ignore the deadlines and missed the reminders ?
>>>> (some unaffected project teams also do not do releases, and therefore
>>>> ignore the release countdown emails)
>>> In my case, not so much "ignore" but "put off until tomorrow" where
>>> tomorrow turned in to 6 weeks.  I really don't have a hard reason
>>> other than simply not prioritizing it because I knew one of the goals
>>> was going to take some coordination work
>> +1 - this has been my case, unfortunately.
>> A patch submission has the feeling of a major thing that goes through
>> a lot of process (at least still in my head). I wonder if we would be
>> better off tracking some of this through a wiki page or even an
>> etherpad, with just the completion of the goal being something
>> submitted to the repo. Then it would be really easy to update at any
>> point with notes like "WIP patch put up but still working on it" along
>> the way.
> The review process for this type of governance patch is pretty light
> (they fall under the one-week-no-objections house rule), but I
> decided to use a patch instead of the wiki specifically because it
> allows for feedback. We've had several cases where teams didn't
> provide enough detail or didn't think a goal applied to them when
> it did (deploying with WSGI came up at least once).  Wiki changes
> can be tracked, but if someone has a question they have to go track
> down the author in some other venue to get it answered.
> I also didn't want teams to have to keep anything up to date during
> the cycle, because I didn't want this to be yet another "status
> report". Each goal needs at most 2 patches: one at the start of the
> cycle to acknowledge and point to whatever other artifacts are being
> used for tracking the work already, and then one at the end of the
> cycle to indicate how much of the work was completed and what the
> next steps are. We tied the process deadlines to existing deadlines
> when we thought teams would already be thinking of these sorts of
> topics (most teams have spec deadlines around milestone 1 and then
> everyone has the same release date at the end of the cycle).

I can sympathize with the "do it tomorrow" turns into 6 weeks later...

Part of the issue for me, personally, is that a governance patch does *not* feel simple or lightweight. I assume (in part based on experience) that any governance patch I propose will be closely examined and I will be forced to justify every corner case and comment made. Frankly, writing the patch that will stand up too a critical eye will take a long time. I'll do it tomorrow...

Let's take the py3 goal as an example. Note: I am *not* wanting to get into a discussion about particular py3 issues or whatever. This is a discussion on the goals process, and I'm only using one of the current goals as an example of why I haven't proposed a governance patch for it.

Swift does not support Py3. So clearly, there's work to be done to meet the goal. I've talked with others in the community about some of the blockers and concerns about porting to Py3. Several of the concerns are not trivial and will take substantial work to overcome[1]. A governance patch will need to list these issues, but I don't know if this is a complete list. If I propose a list that's incomplete, I feel like I'll be judged on the list I first proposed ("you finished the list, why doesn't it work?") instead of being a more dynamic process. I need to spend more time understanding what the issues are to make sure I have a complete list. I'll propose that patch tomorrow...

The outstanding work to get Py3 support in Swift is very large. Yet there are more goals being discussed now, and there's no way I can get Py3 support in Swift in Pike. Or Queens. Or probably Rocky either. That's not to say it isn't an important goal, but the scope combined with the TC deadline means that my governance patch for this goal (the tl;dr version is "not gonna happen") has to address this in sufficient detail to stand up to review by TC members who are on the PSF! I guess I'll start writing that tomorrow...

While I know that Py3 support is important, I also have to prioritize it against other important things. My employer has prioritized certain features because that directly impacts our ability to add customers (which directly affects my ability to get paid). Other employers in the community are doing the same for their employees. In the broader community, as clusters have grown over the years, certain original design decisions are showing their age and actively causing operator pain. Perhaps we can survive for a while longer without solving these (we managed to ignore these issues for the last five years), but as time passes these pain points actually become reasons to use a different storage system other than Swift. We can't ignore stuff like container sharding and improving capacity adjustments any longer. Furthermore, we've got plans underway (in part to solve some of the aforementioned issues) to replace Python code with Golang code. That makes a Py3 port that much easier, but it's work that competes with the porting work in other parts of the codebase. Add in to all this that I've talked to exactly zero people who could not use Swift because it's written in Py2, and the prioritization of the Py3 port gets very easy. But writing a governance patch to say that the Py3 work can't be prioritized is confrontational. So let's put it off until tomorrow...

There's been work in the past to port Swift to Py3. I'm grateful to all those people who have spent the time and effort to move Swift closer to Py3 support. Py3 port patches are *not* simple to review, and we've had at lest 2 or 3 significant regressions that were introduced because of porting work. The Py3 port patches are hard to review, and after reviewing a few multi-thousand line patches that appear to mostly be syntactic but might in fact be hiding a subtle error, it's hard to maintain the motivation to pick up Py3 port patches over other important patches to review[2]. Knowing that the Py3 patches are hard for the community to review, it's hard to estimate how long the porting process will take and even harder to commit to the completion dates the TC set for them. There's progress being made, but it's really slow. I'll put off proposing the governance patch until we can show some better progress. I'll propose the patch tomorrow...

And here we are today. Six weeks after the deadline for getting the initial patch in. The Py3 goal is only used as an example, but I think there are some fundamental systemic issues with the goals process and community, as Thierry suggested. I don't know what exactly they are, much less what the answers are, but I submit my personal experience as evidence in the open.

I should propose that governance patch soon. Maybe tomorrow...


[1] https://gist.github.com/tipabu/833b03a865dba96e9fa2230b82f5d075 is a scratch space for some of the issues. I hesitated to link this, because it is not the place to have discussion on particular issues, but it's some of the things that we're looking at.

[2] https://youtu.be/voXVTjwnn-U?t=31m is an insightful segment on the impact of these sorts of refactors and porting work

>>>> - Is it that in periods of resource constriction, having release-wide
>>>> goals is just too ambitious ? (although anecdotal data shows that most
>>>> projects have already completed their goals)
>>> While this may certainly be a possibility, I don't think we should
>>> give in to the temptation to blame too much on losing people.  OSC was
>>> hit by this too, yet the loss of core and contributors did not affect
>>> the goals not getting done, that falls squarely on the PTL in this
>>> case.
>>>> - Is it that the goals should be more clearly owned by the community
>>>> beyond just the TC? (and therefore the goals should be maintained in a
>>>> repository with simpler approval rules and a larger approval group)
>>> I do think that at least the perception of the goals being community
>>> things should be increased if we can.  We fall in to the problem of
>>> the TC proposing something and getting pushback about projects being
>>> forced to do more work, yet we hear so much about how the TC needs to
>>> take more leadership in technical direction (see TC vision feedback
>>> for the latest round of this).
>>> I'm not sure that the actual repo is the issue, are we having problems
>>> getting reviews to approve these?  I don't see this but I'm also not
>>> tracking the time to takes for them to get approved.
>>> I believe it is just going to have to be a social thing that we need
>>> to continue to push forward.
>> What if we also require +1 from the "core six" projects on goal proposals?
>> If we at least have buy in from those projects, then we can know that we
>> should be able to get them as a minimum, with other projects more than
>> likely to then follow suit.
> Because we do not want to structure our governance in such a way that
> some projects are more equal than others.
> Everyone in the community has an opportunity to respond to the goals
> through the review process. If we don't trust the TC to take those
> responses into account, then we might as well drop the whole idea of
> community goals.
> Doug
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170523/1e335b6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170523/1e335b6c/attachment.sig>

More information about the OpenStack-dev mailing list