Open Stack

Excerpts from Thomas Goirand's message of 2017-02-21 00:50:35 +0100:
> On 02/19/2017 08:43 PM, Clint Byrum wrote:
> > Excerpts from Thomas Goirand's message of 2017-02-19 00:58:01 +0100:
> >> On 02/18/2017 07:59 AM, Clint Byrum wrote:
> >>> Indeed, DPMT uses all the worst choices for maintaining most of the
> >>> python module packages in Debian. However, something will need to be
> >>> done to spread the load of maintaining the essential libraries, and the
> >>> usual answer to that for Python libraries is DPMT.
> >>
> >> I wish the Python team was more like the Perl one, who really is a well
> >> functioning with a strong team spirit and commitment, with a sense of
> >> collective responsibility. It's far from being the case in the DPMT.
> >>
> >> Moving packages to the DPMT will not magically get you new maintainers.
> >> Even within the team, there's unfortunately *a lot* of strong package
> >> ownership.
> >>
> > 
> > Whatever the issues are with that team, there's a _mountain_ of packages
> > to maintain, and only one team whose charter is to maintain python
> > modules. So we're going to have to deal with the shortcomings of that
> > relationship, or find more OpenStack specific maintainers.
> 
> I think there's a misunderstanding here. What I wrote is that the DPMT
> will *not* maintain packages just because they are pushed to the team,
> you will need to find maintainers for them. So that's the last option of
> your last sentence above that would work. The only issue is, nobody
> cared so far...
> 

I believe your experience is not typical, and the DPMT will in fact
assist with some of the more boring aspects of maintaining those
packages. Are they going to chase new upstream versions? No. But they'll
help with transitions, policy updates, RC bugs, etc.

> > It's also important that the generic libraries
> > we maintain, like stevedore, remain up to date in Debian so they don't
> > fall out of favor with users. Nothing kills a library like old versions
> > breaking apps.
> 
> Stevedore is a very good example. It build-depends on oslotest (to run
> unit tests), which itself needs os-client-config, oslo.config, which
> itself ... no need to continue, once you need oslo.config, you need
> everything else. So to continue to package something like Stevedore, we
> need nearly the full stack. That's equivalent to maintaining all of
> OpenStack (as I wrote: the cherry on top of the cake is the services,
> the bulk work is the Python modules).
> 

We may have to agree to disagree on that. The libraries and clients
should be an order of magnitude simpler than the services to maintain.