[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PEP 453 affects Debian packaging of Python packages



On 2013-09-20 at 10:46:14 -0700, Thomas Kluyver wrote:
> - Write a 'how to keep your distro packager happy' guide for developers.
> E.g. many Python developers don't know that distros will move data files to
> /usr/share, but when you do know, it's easy to write code so that the patch
> to achieve this is trivial.

there is an UpstreamGuide_ on the wiki: it's not python specific, 
but it also has some informations about python, and most of it 
should be pretty language indipendent.

.. _UpstreamGuide: https://wiki.debian.org/UpstreamGuide

> - Have a simple way for developers to submit packaging information without
> having to join Debian teams, file ITP bugs, and all that cruft.

ITP bugs aren't cruft, they are a way to prevent duplication of work, 
which would lead to even more frustration.

> - Put the emphasis on keeping packages up to date and simple, not on
> 'maintainer rights'. Packaging should not be an art form. If someone
> uploads a newer version to Debian mentors (or another submission system),
> the maintainer should get an e-mail. If a package is out of date for more
> than a few days without a clear reason, people should be prodding the
> maintainer to ask what's up. 

A few days are definitely too little: even on the AUR (for Arch Linux) 
to orphan a package one needed to wait 2 weeks after the maintainer 
had been contacted (not just after an upstream release), and that's 
in a distribution that prides itself on being extremely up-to-date, 
no matter what.

Most people working on packaging are volounteers, some of them maybe 
can only work on Debian in the weekend, others maybe can usually 
work every evening, but an upstream release happened to be 
on a week when their paid job had a deadline, and they had 
to work long hours.

> If a maintainer is regularly unresponsive,
> drop the package to team maintainership so that other people can work on
> it. 

That's already what happens (sort of): the MIA_ procedure exists 
exactly to try to contact an unresponsive maintainer and, if 
there is no answer, give up the package for adoption.

It takes more than the two weeks for AUR, but afaik it should take 
less than the 4 months you mentioned: was the MIA team contacted?

.. _MIA: https://wiki.debian.org/Teams/MIA

> for instance, if upstream makes a bugfix release 1.4.3,
> and Debian has 1.4.2, it should be as near as possible one click/one
> command to grab the new version, update the changelog, commit the change,
> upload the package, and whatever else needs doing.

there is a single command, (I believe it's ``svn-upgrade --uscan``) 
which downloads the new version of a package (maintained in svn, 
but I believe there is a similar command for git-buildpackage), 
updates the changelog etc.

The maintainer still has to test the package before uploading, 
but that's something that can only be automatized up to a point.

-- 
Elena ``of Valhalla''


Reply to: