Re: Maintainer field value for the r-pkg-team (was Re: dh-r changes)
On Fri, Jan 12, 2018 at 11:22:29AM +0100, Sébastien Villemot wrote:
> I created the r-pkg-team on tracker.d.o:
> Note that since tracker.d.o does not allow multiple owners for a team, I am
> effectively the only owner there. So don't hesitate to ask me if something
> needs to be modified there. For the time being there is no package associated
> to the team.
> The good news is that Raphaël Hertzog has recently introduced a new feature in
> tracker.d.o which allow us to put team addresses in the Maintainer field. So we
> could decide to put:
> Maintainer: Debian R Packages Team <firstname.lastname@example.org>
> in all the team's packages.
Could you add this information to the Wiki page.
> Then the packages will automatically appear in tracker.d.o (and other tools
> like QA or DMD will also work).
> By subscribing to the team on tracker.d.o, one will get the usual DAK and BTS
> messages (there is a possibility of customizing the precise types of messages).
That means I get those e-mails that were usually sent to the science / med
> Note that for the moment the emails sent to email@example.com
> go to /dev/null, which is not so good if some human tries to contact the team
> at that address; but this is supposed to change in the future.
I need to admit I'll wait until this implemented since it happens that
users try to contact the maintainer and this should be sent to real
persons. In other words: The e-mail address should behave like a
mailing list. Speaking about this: Will we have some kind of "archive"
of these mails? I'm asking with the team metrics project in mind where
also maintainer lists were parsed ...
> An alternative solution for the Maintainer field would be to use the (hopefully
> to be created) firstname.lastname@example.org. But this has the disadvantage that
> one will not be able to fine tune its subscriptions to DAK/BTS messages, since
> all will be sent to the list.
I also think we should have two different addresses: One for general
discussion (= email@example.com) and one for package maintenance
> So, in short, there are two solutions for the Maintainer field:
> 1) firstname.lastname@example.org
> Pros: allows fine-tuning of DAK/BTS message subscriptions
> Cons: human messages go to /dev/null (but this is temporary)
> 2) email@example.com
> Pros: simplicity (only one email address for the team)
> Cons: address does not yet exist (but hopefully will)
> I vote for 1), but I am also fine with 2) if this is preferred.
For the moment I think both are not yet usable with a very slight
preference of 1).