The X-Collab-Maint header
I’ll blush and admit that I’ve always been a bit of the “my package my castle” type. But things change, and now I feel differently about my packages.
I toyed with the idea of adding myself to the low threshold NMU list, but it didn’t make me very happy for several motives:
first and foremost, it places emphasis on the upload as the basic unit of collaboration, whereas I think such unit should be the commit
places the information on a network location, whereas I think the information should be more readily available and near the package itself
uses “non-maintainer upload” to describe itself, which is already something else
Then there is the collab-maint project in Alioth, which is nowadays intended as a general purpose area for small teams or groups of co-maintainers to collaborate in their packages, without needing to create a full-fledged Alioth project. Every DD and many non-DD have write access to it, but a package being there does not mean that its maintainers want other people to use such write access on their packages. But, alas, there is no standard way of saying that you do want people to make use of that access, and how (of such way could also benefit projects that make use of the Debian acl, to advertise the fact).
So, as a first draft to fill in these gaps, I’ve migrated several
packages of mine to the collab-maint umbrella, and added a
X-Collab-Maint header to debian/control to signal that I’m open to
collaborations on them. For me, a header felt the best way to express
this information, since it ends up being very accessible (only one
apt-cache showsrc away). As Zack points out to me, though, having it
in a header doesn’t necessarily mean the source of the header has to be
debian/control forever (think e.g. what debtags does) — this leads to
interesting possibilities, like changing the policy without an upload,
or setting the same policy for a large set of related packages.
As for the contents of the header, I think a reduced vocabulary would work best. As a start, this is the one I’ve been using for my packages:
commit-branch: please commit your stuff into a branch, so that I can review and merge it. Other people could just use commit if they prefer commits to trunk directly.
upload-10: feel free to make an upload with your changes if I haven’t acked them within 10 days. Other people could use upload-with-ack, to signal that you’re happy for other people to upload, but that’d you like to review first. Or even upload-0.
Other stuff that’s could be specified includes whether people making a commit should notify the maintainer or not, before letting the upload day count tick. But, if the idea seems worth it, I’m sure we can debate it to death on -project, or something.