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 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129041445.gc28...@merveille.plessy.net
