Scripsit Raphael Hertzog <[EMAIL PROTECTED]> > I would be in favor of a tighter integration between the PTS and the > <package>@packages.debian.org email address too for example. > > I could implement a default subscription to the PTS for package > maintainers but you first need to solve several problems: > - decide which keywords they will receive by default (all except bts, > bts-control and upload-binary is my choice, and maybe katie-other)
Perhaps we could start by only auto-subscribing the maintainer to a currently unused keyword, say "pdo". The next step would be to start redirecting [EMAIL PROTECTED] to that keyword. Subsequently, services that currently send mail directly to maintainers could be migrated one by one to send only to the PTS, and at the same time the relevant keyword could be added to the auto-subscribe-the-maintainer set. (I would dearly love to do this with the testing migration notices I send out from my "trille" cronjob. There are a handful of maintainers who have asked for a way to opt out, which I have not got around to hack my own implementation for). The ideal, I think, would be to centralize in the PTS *all* automatic emailing to maintainers, such that all everyting be opted into or out of by a common interface. (Hm, one may need except Katie mail that gets sent as a result of the upload that changes the maintainer, but before the PTS gets a chance to take note of the change. Some thought will be needed here. Perhaps Katie ought to piggyback a "by the way, the latest maintainer is NNN" header onto such mail it sends to the PTS - which would also allow the PTS to take note immediately). > - when the maintainer changes, we logically need to unsubcribe the previous. > So this must be recorded somewhere. (it's not a subscription like the > others) This would appear to be main implementation challenge, yes, but I'm not sure I agree with your premise. I think I would find it tedious to distinguish between "keywords I subscribe to as maintainer" and "keywords I subscribe to as myself", so I would prefer a solution where this distinction does not exist, even if it means that I have to explicitly unsubscribe from packages I let go of. How about a crude strategy: Whenever the maintainer of the package changes, the new maintainer automatically gets subscribed to the default keywords *under his own address* and *iff he has no subscription at all to the package already*. The old maintainer does not get unsubscribed (the may still want to follow the package) but is sent a notice reminding him to unsubscribe manually if he wants to get rid of the PTS mail. This would have the advantage of simplicity, both for the implementor _and_ for the maintainers. > - in many cases, the maintainer doesn't want the "diff" since there's a > dedicated mailing list for that on alioth ... is it OK if we leave the > problem up to the maintainer to change the set of keyword accepted ? That would be the point, wouldn't it? Off the top of my head, I don't think that version diffs should be a maintainer-default keyword, for the reason you cite. (But I'm not personally affected by the choice either way, so my opinion may not be important). -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]