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

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



Reply to: