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

Dmitry Tantsur dtantsur at redhat.com
Tue May 23 12:13:35 UTC 2017


Not an offender, apparently, but lemme throw some less optimistic views here.

On 05/23/2017 12:40 PM, Dean Troyer wrote:
> OK, I'll bite, being one of the until-last-week offenders...
> 
> On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez <thierry at openstack.org> wrote:
>> As part of release management we remind projects of the release cycle
>> deadlines, including the ones regarding the release goals process.
>>
>> According to [1], "each PTL is responsible for adding their planning
>> artifact links to the goal document before the first milestone
>> deadline", and "if the goal does not apply to a project or the project
>> has already met the goal, the PTL should explain why that is the case,
>> instead of linking to planning artifacts".
>>
>> However, for Pike goals we are 6 weeks past the pike-1 milestone, and we
>> still have about half the project teams that haven't provided answers
>> (despite two reminders posted in the release countdown emails). Such a
>> large share goes beyond the usual occasional misses, and points to a
>> more systemic issue, that we might want to address before the Queens
>> campaign starts.
>>
>> A few questions to bootstrap the discussion:
>>
>> - Is it that the reporting process is too heavy ? (requiring answers
>> from projects that are obviously unaffected)

I feel like the answer is somewhere here. Maybe filling in a field in a 
spreadsheet could be easier for folks?

> 
> 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
> 
>> - 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.

How do you define "too much" here? We've lost all people who committed to work 
on one of the goals. Does it count?

Also, I'm sorry, but OSC is a bad example here. The WSGI goal did not apply to 
you at all, and I suspect you were already more or less (or fully) Python 3 
compatible.

> 
>> - 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 won't be surprised to learn that these are different people :) Or at least 
that some people do not understand "provide leadership" as "ask to do more work" 
(not meaning anything negative here, especially since I believe that the goals 
we have are important indeed).

But I do agree that there don't seem to be enough buy-in from the community in 
the goals. Probably the reason is well-known: companies backing people do pay 
for that, so they have to prove that working on the goals benefits their employers.

> 
> 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.
> 
> dt
> 




More information about the OpenStack-dev mailing list