Re: Guidelines for packaging projects on Alioth
Scripsit Raphael Hertzog <hertzog@debian.org>
> 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 pkgname@p.d.o 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."
Reply to: