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

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>

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

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
  - 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
- 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.


[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: