* Barry Warsaw <barry@debian.org> [2014-01-26 13:24:38 -0800]:
> I do think we should be switching all team maintained packages to dh_py2 and
> finally getting rid of py-support and py-central (!). For the sake of
> consistency, I'd love to see the latter two just disappear completely, but at
> least we here can work toward modernizing team packages to the newer helper.
>
> The use of dh_py2 is a nice parallel with dh_py3, which is the only helper for
> Python 3. pybuild doesn't eliminate the use of dh_py2 and dh_py3, it's just
> built on top of them and makes supporting bilingual libraries usually really
> easy. I'd personally like to see all of our Py 2/3 compatible libraries use
> it if possible.
Ditto.
> That having been said, if DPMT is in maintainers, I'd say it's a courtesy but
> not requirement to file a bug, and then contact the maintainer about the
> proposed packaging changes. Wait a reasonable amount of time, attach a patch,
> and see if you can have a conversation about it. If DPMT is in uploaders but
> not maintainers, then I think the requirement to contact the maintainer is
> stronger, but I'm not sure it should be *so* strong as to prevent other team
> members from making packaging changes. Maybe require contact with maintainer,
> and a longer waiting period, with a little more deference to the maintainer's
> preferences?
>
> In any case, an email to this list saying "I want to change package foo to use
> pybuild and dhpy2/3 from python-{support,central}, and here's the patch"
> probably wouldn't hurt.
I am strongly of the opinion that the DPMT should be a team, not just a SVN
repository with random packages and a mailing-list where people shout at each
other when they dare touch those packages.
This continuing atmosphere of fear, and the constant bad faith accusations,
make it really hard to work in the team efficiently, and all of this makes the
Python ecosystem in Debian weaker, as some packages which would be relevant for
the team go to collab-maint or other teams instead, and therefore do not get
the level of care and/or expertise they would get otherwise.
It has been a while since I have been meaning to post a message like this. I
have been following the work of the Perl team for a while now and this is
obviously the gold standard we should strive for. Here's a short
TODO-kind-of-list (in no specific order) for making Python module maintenance
in DPMT fun again:
- Kill the meme that people own their packages when the team is in the
maintainer field.
- Dust off the team's PET instance ([1], which looks rather outdated).
- Only have one sponsorship queue. I think the VCS is the obvious place where
that queue should be. PET allows you to list the "packages ready for upload"
(i.e. packages where debian/changelog says that an upload is ready). When a
reviewer thinks a package is not fit for upload, just unreleases and adds TODO
items to d/changelog, so that the sponsoree knows what to do.
- Be more welcoming to newcomers. I think that the "proof of previous work"
policy is a hurdle that we would be better off without. The worst that could
happen is that someone starts packaging something and then the package
languishes in svn. If we get some tools to help ourselves manage our packages
(and I honestly think PET is that tool), then I don't see what's next.
- Amend the Python Modules policy to stop mentioning deprecated helpers.
- Get rid of python-support.
- Try to standardize on pybuild instead of cargo-culting debian/rules.
- Adding Python 3 support when upstream has it, or even contributing it
upstream.
- Getting rid of Python 2 in "standard" installs (that work is well underway
AIUI).
- General package gardening (bugfixes, upstream updates, merging ubuntu
changes, unused package removals ...)
(I'm afraid to put this in here, as it's mostly a matter of taste, but)
- Migration to a more modern VCS. A few weeks back, I started to toy around
with svn-all-fast-export on the DPMT repo. I had to lightly patch it to do
what I wanted it to do, but the result is up on alioth[2]. It's a first take at
the issue, and there are a lot of kinks to work out. The scripts I used are
available[3] for scrutiny. Please don't take this as an occasion to rehash the
same arguments all over again: just talk if you want to take this further.
Obviously all of this means work. I'd be glad to put my money where my mouth is
on some of those tasks if there is general consensus that they would be useful
things to work on. For instance, as a first task, I'd be happy to do whatever
is necessary to get our PET instance to work again, as this is a valuable tool
to manage the number of packages we have to.
I'll probably be a bit busy this week as I have a FOSDEM talk to prepare.
However, I'm pretty much always around on IRC and, well, I'll be in Brussels
this week-end so if some of you happen to be here too you can hit me up and we
can discuss all of this around a $BEVERAGE or three.
Cheers,
Nicolas Dandrimont
[1] - http://python-modules.alioth.debian.org/cgi-bin/pet.cgi
[2] - git.debian.org:~olasd/public_git/dpmt/
[3] - git.debian.org:~olasd/dpmt_migration/ [see tools/bin/{dpmt-rules-gen,dpmt-svn2git}]
--
BOFH excuse #431:
Borg implants are failing
Attachment:
signature.asc
Description: Digital signature