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

Bug#507288: mails to $pkg@p.d.o should also be send to Uploaders:



Le lundi 1 décembre 2008 08:39:23, vous avez écrit :
> Hi,
> 
> On Sun, 30 Nov 2008, Holger Levsen wrote:
> > On Sunday 30 November 2008 10:49, Raphael Hertzog wrote:
> > > Holger your request is not really acceptable in the current situation
> > > but I also think that Uploaders/Maintainers should be auto-subscribed
> > > and that we should simplify the situation by having all services mail
> > > directly the PTS. And after that we can reevaluate the situation. Feel
> > > free to start the discussion with ftpmasters and bugmasters, those are
> > > the two most important services that would let us generalize this
> > > principle.
> > 
> > I do not understand, what I should discuss with ftpmasters and bugmasters
> > here. Really. Can you repeat please? There was some enlightment in this
> > thread, but not enough so that I understand why this cannot simply be
> > done in the PTS.
> 
> Currently Dak and debbugs mail directly the Maintainer and send a copy to
> the PTS. Other services mail pkg@packages.d.o and this one also mails the
> Maintainer and send a copy the PTS.
> 
> You ask to modify the PTS to mail the Uploaders and I respond that it's
> not a wise choice because nobody can disable the mails sent directly to
> the maintainer.
> 
> If we can get the Dak and debbugs to mail only the PTS, then we can code
> the PTS to auto-subscribe either the Maintainer or all the Uploaders (or
> both) and leave the choice to each team (or each member) to override the
> default configuration.
> 
> Cheers,

As pointed out by jcristau and mehdi on IRC a while ago (sorry for that), 
auto-subscribe both the Uploaders and Maintainer would lead to a lot of 
duplicate mails. Indeed, it's often the case that the Maintainer field contains 
a mailing list some of whose members are also in the Uploader field. I guess 
this would mean #481315 can't be solved for the same reason (correct me if I'm 
wrong).

So it leaves us with auto-subscribe the Maintainer or all the Uploader, the 
former having the advantage of not changing the current situation but allowing 
people in the Maintainer field to tweak the mail they receives (as someone who 
register to the PTS can do).

As a first step, I attach is a tiny patch which should remove the sending of 
mail by dak to the maintainer. To avoid any disruption I believe it should be 
activated in dak when the PTS will be able to auto-subscribe people in 
Maintainer field.

Best regards.
From e9f8a6a18e47fe8e7c9b9f83cd123be1838caa27 Mon Sep 17 00:00:00 2001
From: Thomas Preud'homme <robotux@celest.fr>
Date: Thu, 15 Sep 2011 15:21:49 +0200
Subject: [PATCH] Don't email maintainer if PTS can be used instead.

Only email maintainer if PTS can't be used to reach him in order to
address #507288. See in particular message #107 [1]

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507288#107
---
 daklib/queue.py |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/daklib/queue.py b/daklib/queue.py
index f659339..ef720a1 100755
--- a/daklib/queue.py
+++ b/daklib/queue.py
@@ -500,7 +500,10 @@ class Upload(object):
            (self.pkg.changes["changedby822"] != self.pkg.changes["maintainer822"]):
 
             self.Subst["__MAINTAINER_FROM__"] = self.pkg.changes["changedby2047"]
-            self.Subst["__MAINTAINER_TO__"] = "%s, %s" % (self.pkg.changes["changedby2047"], self.pkg.changes["maintainer2047"])
+            self.Subst["__MAINTAINER_TO__"] = "%s" % self.pkg.changes["changedby2047"]
+	    # Use PTS for maitainer if we can
+            if not cnf.has_key("Dinstall::TrackingServer") or not self.pkg.changes.has_key("source"):
+                self.Subst["__MAINTAINER_TO__"] += ", %s" % self.pkg.changes["maintainer2047"]
             self.Subst["__MAINTAINER__"] = self.pkg.changes.get("changed-by", "Unknown")
         else:
             self.Subst["__MAINTAINER_FROM__"] = self.pkg.changes["maintainer2047"]
-- 
1.7.7.1

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: