Re: DEP-2: Debian Package Maintenance Hub
Hello Raphaël,
I like the idea of a Debian package maintenance hub that would extend and
replace the PTS, and consolidate available information in a single place. This
is especially useful as e-mail as a communication medium is declining. Spam is
abusing our mailboxes and our infrastructure, to the point that without
countermeasures the service is useless, and with the countermeasures it is not
reliable anymore. If the maintainance hub can provide a reasonnable default
information feed per maintainer, it will be a great tool.
I have a couple of comments and questions about your implementation details.
- It would be great to integrate it with Debian Pure Blends, so that
a maintainer knows that his package is part of one of them.
- I like the current workflow to decide who is maintainer: it is defined
by the last person who uploaded the package. This our do-o-cracy.
For unmaintained package, we have the [O] bugs in the WNPP pseudo-package.
If the canonical place for information is the Hub, who will decide who
is maintainer ? I think that the source package, and its VCS, are the
most appropriate canonical place for such information. Now that we
have “team uploads”, there is less needed to be listed in the Uploaders
field for occasional help, so the best I think is to use this field
to record who is responsible, and the Maintainer field to record where
the information is sent. The Hub you propose will facilitate this a lot.
- <package>@packages.debian.org is a special user for BTS usertags.
It would be great to integrate these settings in the Hub, and
perhaps provide some facilities to packaging teams for managing
these settings globally.
- If the Hub could provide a feed in containing all the commits from one's
team, plus all the commits from his packages, that could be very useful.
VCS commit messages are becoming an integral part of the information flow in
package development. But on the other hand, I spend more and more time
deleting commit messages that I do not read. As an example, I have packages in
the Debian Med and Debian Perl and Science repositories, but I do not want to
read all the commits of the Debian Perl and Science team, in which my
participation is far lower than in the Debian Med team.
- About the endorsements or commitments discussed on the side of this DEP, I
think that it is very important to keep them entirely optional. I have
a work contract that includes overtime, and responsibilities where I am
expected to be fully committed to my work. On top of this, my commitment
to the projects for which I recieve governmental support is recorded in
central databases, in order to avoid funded people to declare more than 100%
commitment. In that context, I do not want to give any written commitment
to the Debian future. One can see what I did in the past, and it is not
unreasonable to think that I can do the same in the future if my situation
does not change, but formally, I promise nothing. I may stop everything
anytime without notice.
Lastly, perhaps the DEP can discuss brifely why a new development is necessary,
compared to using or extending existing tools, such as Launchpad or other
forges.
Cheers,
--
Charles
Reply to: