Re: How does team maintenace of python module works?

[Thomas Kluyver <thomas@kluyver.me.uk>]

On 14 February 2013 22:54, Matthias Klose <doko@debian.org> wrote:

> That causes problems when newcomers don't want to learn
> deprecated packaging methods, and aren't allowed to update packages to use
> the recommended helper.

Agreed, so why not helping with it? Again, why not helping here?

I'm not sure what you're suggesting I do. I consider myself to be a newcomer in more or less the situation I described. I've got better things to do than learn the workings of python-support, but switching a package to dh_python2 is apparently a major change, which only named maintainers can approve. And if the maintainers aren't interested, the old helper can remain indefinitely.

Also, between this sort of thing, and the tense atmosphere I sometimes feel this list has, I'm not especially motivated to contribute here. The effort/satisfaction ratio isn't as good as many other projects I can spend time on.

 

> Back on the VCS question, I fear that the 'all or nothing' road will circle
> back to 'nothing' for a long time. I think that we should allow some
> packages to live in git without forcing a complete migration, so individual
> maintainers can use the VCS they're more comfortable with. Most open source
> programmers have at least a basic familiarity with both, so it shouldn't be
> such an obstacle to working on other packages.
>
> We wouldn't be the only team doing this - Debian Games Team, for example,
> use both git and svn for packaging:
> http://wiki.debian.org/Games/VCS

Now you did point out one discrepancy, which hinders newcomers, and you do want
to introduce another one?

The distinction I was trying to make is that open source developers often already know the basics of multiple VCSs, because they've contribute to different projects. By contrast, the different packaging helpers are entirely specific to packaging Python modules within Debian, so newcomers have to learn them for this specific task. So there's less penalty to having multiple VCSs coexisting.

But I don't feel strongly about this point - it looks like we want to maintain a single team VCS, and that's fine by me.

Thomas