Idea for maintaining packages up for adoption
(resending this mail because I sent by error to email@example.com instead
of firstname.lastname@example.org, please include debian-qa in copy if you reply
to the first part of the message, please note I'm not subscribed to
I gave a talk about Debian-QA last week during the Libre Software
Meeting in Dijon.
At the end we had an interesting discussion concerning the packages
which have a very small userbase and for which we have troubles to find
a maintainer : oprhaned/unmaintained packages !
I discussed this with Benjamin Bayart who is a TeX expert and gave me
some examples concerning some small packages like "dvi2dvi". He's not
willing to go through NM to become a Debian Maintainer because that's
too much hassle just for maintaining one or two little packages like
this one. The bulk work for those packages has been done and they're
mostly in "maintenance mode"... they don't represent too much work.
In the end, we decided to remove several packages he's using because we
couldn't find a maintainer for them.
The problem is then : we have knowledgeable people willing to help but
we don't have a Debian maintainer for them. Benjamin sent several patchs
in the BTS and they are still there... waiting to be applied.
The suggestion I made is the following : let's co-maintain all those
packages on alioth (with Subversion) ! We'd give access to any outsider
who has a patch ready to be applied... all the packages could be built
automatically and sometimes the outsider could ask for a "sponsor
upload" to update it in the main archive.
This is mostly how the maintenance of perl module works now, so I see no
reason why it couldn't work in this case.
This is the basic idea but we have to define a more precise policy :
- which packages are concerned ? (Orphaned, RFA?)
- what can we automate in this ? (automatic inclusion of new orphaned
packages in particular)
- I think it should completely replace the actual way of maintaining
orphaned packages... this would at least enable real cooperation within
the QA team. Otherwise we never know who is working on which package...
and it's difficult to synchronize.
- the "outsiders" who are regular helpers should be listed somewhere in
the package (debian/maintainers file ?) ... maybe one should even be
listed as "Maintainer" in debian/control ... there's no point in keeping
the email@example.com email listed as maintainer. Those outsiders
would be required to subscribe to the PTS of the given package.
- where should the "outsiders" be directed to when they need to upload a
new version to Debian ? Debian-qa ? debian-mentors ? somewhere new ?
- if we go that route, we need to publicize this new system so that the
users of those "unmaintained packages" have a chance to help. It's also
a way to let the upstream author help us without requiring him to go
(In the longer term, some maintainers may even choose to continue to
maintain the package within that infrastructure just because it's
convenient and doesn't require a dedicated alioth project just for a
What do people think of this idea ? Any volunteer to setup the required
Another idea in this direction would be the following : I consider that
Benjamin is able to maintain the little TeX packages and I'm pretty sure
if he could upload them himself, he would do a good job. He's probably
not able to maintain "any" Debian package and going through NM would
require work from him that he's not willing to do. Does that justify
that we forbid him to maintain the TeX packages that he's able to
handle ? I think "no".
=> we could add GPG keys with limited rights. Benjamin's key would only
allow him to upload the TeX related packages he's maintaining.
(firstname.lastname@example.org in copy because of that part)
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org