Re: DEP-2: Debian Package Maintenance Hub
* Raphael Hertzog <hertzog@debian.org> [120130 08:50]:
> I won't deny that it would be cleaner if all the Debian services could
> send the information directly to this infrastructure only, but we had this
> discussion multiple times with the PTS already and we never seemed to have
> any sort of buy in from ftpmasters or BTS maintainers.
>
> (And somehow I can understand them, I wouldn't want to denaturate the
> software to stop sending mails to the Maintainer since that's the right
> thing to do in the generic case)
>
> That's why I picked this approach which allows to start even if we don't
> have buy in from some key teams and even if some maintainers are opposed to
> the new approach.
Well, as long as your approach is some wild hack that will either lead
to duplicate mail or racy sitatuation where mail can be lost I
definitely know that I will be opposed.
And I really do not see why maintainers should trust a system if they
are told it is that kludgy because the key Debian infrastructure
maintainers thinks it is not good enough to actually be used.
> > Information source do not need to send copies, they do not have to care
> > about "Maintainer:" or "Uploader:", just a single way to send stuff.
> > (And if anything wants to have a mode for non-Debian it still needs to
> > know when to send a copy to the PTS or this new service, so just only
> > sending it once in that case makes things only simpler even then).
>
> The copy to the PTS has been implemented everywhere as a configuration
> option that's empty by default so there's no "logic" to decide when it needs
> to send a copy to the PTS.
A config option is a logic. The logic to have some configuration option
to send a copy to the PTS or not and the pts email and format either
hardcoded or configurable is no more complex than some configuration
option to submit only to an all-inclusive service.
> > Maintainers do not need to change their packages instantly (and most
> > packages might not need any changing at all). As uploader-,
> > maintainer- and subscription mail is sent by the same service, it could
> > offer settings like "send mails for this package to this address instead
> > of my old maintainer address in stable" or "don't send me a copy if this
> > mailing list also gets a copy" or "send me a copy for things I'm
> > uploader unless I already get a copy" instantly.
>
> We get those benefits with the new infrastructure in all cases (whether or
> not we change the Maintainer field).
If you are in the maintainer field and you are also subscribed to some
email list that gets all traffic for this package, you get duplicate
mails if there is something still mailing maintainers directly.
Bernhard R. Link
Reply to: