How to make things change - need some help
Hello everybody,
the QA group will soon provide a new service[1]. The ability to subscribe
to packages : when you're subscribed to a package you get all
the BTS mails that the maintainer is getting.
How does it work ?
You can (un)subscribe to a package by sending a mail to
control@packages.qa.debian.org. The possible commands are :
subscribe <srcpackage>
subscribe <srcpackage> <email>
unsubscribe <srcpackage>
unsubscribe <srcpackage> <email>
quit
This part does work and is ready (a bit of testing is always
appreciated though). Once you're subscribed you get
the mails sent to <srcpackage>@packages.qa.debian.org (the BTS will be
modified to send mails to this adress at the same time it sends mails
to the maintainer). The mails sent have an header (X-Loop:
<srcpkg>@packages.qa.debian.org) that lets you easily filter it
in a special mailbox if needed.
I believe this service was one of the last missing piece to let
easily more people work on the same package. Now, we'll have to try to
popularize this service by explaining how it can be intelligently used.
We have to document it wherever it's needed :
- Debian Developer's Reference
- New Maintainer Guide (you'll know why soon)
- Debian QA web site
- mails to debian-devel-announce
But I need your help to update those docs, and I need your ideas as
well.
First, i'll present you the different possible uses of this service
that I (and aj) have imagined. If you think about other possible uses,
please tell us. :)
* It can be used by "backup maintainers" to follow a package. I believe
we should encourage all maintainers to look for backup maintainers who
can help, do the work during vacation of the main maintainer, check
that the package gets the attention it needs to have.
* It can be used by upstream authors who wish to follow how their
package is handled within Debian. Those who are using Debian can
be of great help ...
* It can be used by QA workers who decide to help a maintainer
to clean his package. You can work with several QA workers, they
all get the BTS changes and follow what new information is
provided and so on. They get the patches sent to the BTS, and so on.
* It can (and i'd like to say "should") be used by NMUers to follow
the package during a complete week after they uploaded their NMU to see
if they introduced any bugs ...
* It can be used by sponsor to follow the work of their applicant
(future maintainer).
* It can be used by applicants to see how an experienced developer
is managing bugs.
* It can be used by people making their own debian derivated distro,
they can actually follow the update (we may also change katie to
make it notify <src>@packages.qa.d.o when a new source package has
been installed).
* Anything else ? Please tell me ... :)
Well, now we need to document those possibles usages wherever it
is useful.
For the Debian Developer's Reference I have several other things
that we should change as well... and I need your input for that.
I'd like to add 2 chapters to it :
* The first one would be "Collaborative maintenance of a package".
It would explain the benefits of maintaining a package with a
little team. It would explain what is available to ease that
team work. Please complete the list :
- use the package subscription feature to let co-maintainers also
get the bug report (without the need for a specialized mailing
list)
- use Uploaders: field (how is it working exactly ?) in order to
let several people upload without considering those uploads as NMU
- use CVS if you want/can/need to (a special tool ? cvs-buildpackage ?)
- invite (propose to) upstream developers who are using Debian
to subscribe to the package
- what else could be mentionned ?
* The second one could be "Going further than simple maintainer".
It would explain what a debian developer {can|should} do for Debian
apart from well maintaining his own packages. That includes :
- sponsorship work on debian-mentors
- doing Application Manager for the New Maintainer team
- join debian-qa and help
- join debian-boot and work on debian-installer
- participate in Bug Squash parties
- voting when a vote is conducted
- what else ?
I cced the developers-reference maintainer to have its opinion about
what I propose here. The explanation behind this proposal is that
i really think that we need to emphasize our message about
how we want (future) developers to work. We have to show them the
path (at least the direction :)) to follow :
- more eyes/package, more maintainers/package => a package is less
likely to be forgotten and non-maintained, more bugs could also be
corrected
- more transparency with the upstream maintainer => we need to attract
the few upstream authors who care about debian ang give them the
opportunity to directly help the debian maintainer
- there's more than your own package, we need people everywhere, in
particular we always need confirmed developers to sponsor the
applicants (that's the best way to actually explain them what
we do expect from them) and more help in QA (in particular fixing RCB).
Now, your feedback is welcome. I also accept volunteers who'd like
to write (parts of) the missing piece of documentation.
Cheers,
[1] Anthony Towns still has to make some modifications to the BTS.
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: