Re: DEP-2: Debian Package Maintenance Hub
On Tue, 31 Jan 2012, Bernhard R. Link wrote:
> * Raphael Hertzog <hertzog@debian.org> [120130 08:50]:
> > 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.
Thanks for proving my point. :-)
> 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.
There's a difference between "not good enough to actually be used" and
"I don't want to modify the way our tools work to integrate with an
infrastructure which has not yet proven that it will be up to the task".
It's easier to convince people with a working implementation than with
a design (even if it's nice and well thought out).
> > > 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.
Yes, but there's a logic which has already been implemented and a logic
which will require further changes to the current code.
Any requirement that we set on pre-existing infrastructure makes it more
difficult to have the buy-in of everybody involved and more difficult to
coordinate the setup/transition.
Any external requirement
Any
>
> > > 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.
In your scheme, the Maintainer field would not be used, only the new
infrastructure would be. So there would be no duplicates.
In the suggested scheme, the Maintainer field is modified to point
to <source>@pkgmaint.debian.org so you stop getting mails via Maintainer
and you also don't have duplicates.
So unless you manually subscribe mailing to the new infrastructure (which
is a no-no given the goals), you should not get duplicates.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: