Open Stack

Excerpts from Ian Cordasco's message of 2016-05-05 16:10:09 -0500:
>  
> 
> -----Original Message-----
> From: Haïkel <hguemar at fedoraproject.org>
> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Date: May 5, 2016 at 15:25:08
> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements
> 
> > Well, I'm more in favor having it as a sub-team of release mgmt team.
> 
> I have to agree.
> 
> Doug, did you have specific ideas about what a PTL for the requirements team would do? It's not inherently obvious to me what the benefits of having a requirements PTL would be.

The dependencies list was placed under the release team sort of as a
default -- it didn't fit with any project teams, and we knew we would
have to manage freezing the list at certain times in the cycle. I have
full faith that a new standalone team will work with the release team on
that coordination.

Now that we have a lot of projects to manage, the release work takes
a bigger proportion of the release team's time over the entire span
of the cycle.  So it's not so much that a dependency management team
needs to exist in its own right as that the work such a team might do is
being mostly ignored by your current release PTL (me) because of other
priorities, and that's not a good situation for any of us.

Managing the list of dependencies is not quite a full time job, but
it's a focused set of responsibilities that can be carved out from the
current release team duties.  As far as other work, in the short term
there's quite a bit of cleanup to be done of the current dependency
list, and there are a few ongoing projects related to constraints and
other changes to how we manage and use the list that need someone to
drive them. I think having a separate team to own that work will be more
effective than what we have now. Eventually I expect it to settle back
down into a relatively low-level of effort to maintain the list.

Doug