[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP-2: Debian Package Maintenance Hub



On Tue, 31 Jan 2012, Bernhard R. Link wrote:
> 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.

Duplicates are vastly preferable over lost mail.  We've been able to kill
duplicates automatically on the receiving end for what, 15 years?

That said, stuff should be _designed_ to be able to avoid duplicates, even
if it means we have to manually configure something in db.debian.org or
p.qa.d.o to disable whichever one we don't want.  However, if at any moment
one must be faced with "might lose mail" or "might cause dups", dups it is.

> 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.

Well, that's fair.  Lost mail due to a mail blackhole (some package ends up
with _no_ forwarding address and maintainers are not mailed directly
anymore, for example) is not acceptable, so get the entire system to be
resilient and trustable enough for the DSA team to accept it before it is
placed in the *middle* of the mail path instead of to the _side_ of the mail
path (like the PTS is currently).

If it ain't broken, don't try to fix it.  The way the PTS currently works
re. mail notifications seems to be optimal, it is low-risk for the mail
path, and you can opt-in/opt-out as needed to request or avoid duplicates.

When the PTS is down, I do NOT lose any important BTS/package email. I don't
much like the fact that a problem with the mail forwarding of @debian.org
would break everything, but we had what, at most two such incidents in the
last 10 years?

> 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.

That you should deal with it on your end.  If it bothers you, either
sort/filter the messages properly, or do duplicate suppresion.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


Reply to: