package: package.qa.debian.org
severity: wishlist

Hi,

currently, mails send to $pkg@p.d.o are only send to the address listed in
maintainers and to those subscribed to the PTS. IMO they also should be send
to the addresses in Uploaders:. Please do so.


regards,
	Holger

+1

Cheers,

Holger Levsen <holger@layer-acht.org> writes:

This does the wrong thing if the maintainer is a mailing list and
Uploaders are the people who do the uploads, doesn't it?  I generally want
to get such mail only once, via the mailing list.

Hi,

No, it doesn't.

I prefer duplicate mails over mails lost.


regards,
	Holger

that word exists) mails but I want to receive mails at least once.

My personal approach for getting rid of the already existing multiple
instances of the same mail is a simple procmail recipe [0]; and since
the problem of duplicate mails already exists anyway (and needs to be
handled anyway) I second Holger's suggestion.

Cheers,
gregor

[0]
taken from man procmail$something:

# duplicates
:0 Wh: msgid.lock
| formail -D 32768 msgid.cache

* Holger Levsen [Sat, 29 Nov 2008 20:27:19 +0100]:

Why? Uploaders are probably subscribed to the PTS, *or* the maintainer
is a mailing list.

Hi,

not always.


regards,
	Holger

IMO subscribing to the PTS for packages where I'm "just" in the
Uploaders field is a hassle that can easily be forgot.

Cheers,
gregor

* Holger Levsen [Sun, 30 Nov 2008 01:34:03 +0100]:

Then that uploader does not want to receive mail, period. Unless you go
and use their address directly.

(One could say that they should receive the mail nevertheless because
they've put their name in the control file. That's a valid point of
view, but that's not the "status quo", and it's debatable whether it
should be that way, because the subscription to the PTS is the canonical
way for co-maintianers to work (modulo mailing lists as maintianer).)

Hi,

Yes, it's debatable and I think the current status is wrong. The canonical way
should be that maintainers: and uploaders: always get mails, whether they're
subscribed or not.

As Herman wrote, one has to filter anyway, so..


regards,
	Holger

Holger Levsen <holger@layer-acht.org> (30/11/2008):

dpkg-reconfigure $user, then. Not a PTS bug, at least seen from here.

Mraw,
KiBi.

gregor herrmann <gregoa@debian.org> writes:

This doesn't work properly with mail splitting based on List-Id headers,
since procmail frequently discards the mail to the mailing list instead of
the (duplicate and unwanted) personal e-mail that doesn't sort into the
proper folder.  You can work around it by splitting mail based on the To
and Cc headers instead of the standardized List-Id header, but that's not
as clean.

I have no objections to this being added if there's some way to turn it
off.

Ack, I also see this annoyance here.

Sounds like a good idea to me.

Cheers,
gregor

I really think that the only way to solve that in a definitive way would be:

1/ Improve PTS' mail handling (it still has some rough edges)

2/ Strongly encourage people to subscribe to their packages on the PTS

3/ Make all services send mail to the PTS, and stop sending mail
   directly to maintainers/uploaders

Like what?

I mostly agree with Lucas…

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.

Cheers,

Minor UI annoyances: the fact that, when you subscribe to 10 packages in
one email, you get 10 emails in reply, that you each have to confirm
separately [that was the case some time ago, not sure if it's still the
case].

More generally, it's currently not easy to have a team subscribed to all
its packages. Maybe we could have a way to automatically subscribe
someone (team or developer) to a set of packages, using the same
keywords.
Something simple, like a cron script run daily, that would take a list
of emails, and would subscribe each email to each package for which the
mail is in Maintainer or Uploaders. (The list of emails could be managed
by the qa group).

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


regards,
	Holger

P.S.: no need to cc: me on this (or any other QA) bug.

They are two different things.
AFAICT the latter is handled by the PTS, the former is not.

Cheers.

So how about doing this only if maintainer does not match
"@lists\.(alioth\.)?debian\.org$"?

Ben.

Ben Hutchings <ben@decadent.org.uk> writes:

I'm not sure if that would solve everyone's possible problem (there may be
non-debian.org maintainer lists), but it would definitely solve mine.  All
of my maintainer mailing lists are hosted at debian.org.

Hi,

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,

Hi,

While I really like the long term goal, I think that the problem is too
complex to be addressed by just asking dak/debbugs people to change
their behaviour.

If someone cares enough about that to work on it, I'd like to see a
document (DEP-like) that would include:
- current state of mail handling in Debian, because it's not clear for
  most of us
- possible evolution
  + needed changes in services
    - including PTS improvements
  + transition plan, so nobody will lose important mails about one's
    packages during the transition
- possible low-hanging benefits?
  + RSS feeds instead of email notifications?

If we go this path, we will have to automatically subscribe some emails
to the PTS, but allow that to be overriden.

Hi Stefano,

I really ment the former, though the behaviour should be the same for the
latter too, AFAICS.


regards,
	Holger

I second this proposal, it seems to really be what we need.
Unfortunately, I don't see myself having the energy to pursue that in
the near future, hence I'm not volunteering to be a driver.

Any takers?

Cheers.

Le lundi 1 décembre 2008 08:39:23, vous avez écrit :

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.

Hi,

I have started to work on a DEP that is a bit broader in scope but that
should fix this at the same time.

http://dep.debian.net/deps/dep2/

In fact I combine an old idea that I already exposed (about tracking
commitments) with a central infrastructure to dispatch information to
package maintainers.

The draft is not complete but it explains the basic issue, a simple
solution to the problem of information flow, and a simple transition
plan.

Comments are welcome and supplementary drivers are also accepted.

I expect that the most difficult part will be to decide how to deal with
the "commitment tracking" part. What should we log? What sort of
relationships should be defined and what should they imply (in terms of
default set of information provided, and of associated commitments)? Etc.

Cheers,

Thanks a lot for doing this!

There many many things in it that I like and that I think should be
pushed forward, quoting some of them from your initial draft:

- The flow of information is not the same depending on whether you're
  listed in the Maintainer field
- The Uploaders field is often outdated
- Support alternate notification systems
- forward the relevant information by other means (RSS, XMPP, IRC,
  etc.).
- new maintainers can then have access to some historic information that
  used to be private for no good reasons
- solves the problem of maintainers who orphan their packages and are
  still listed as maintainers in many released packages

the principle I like the most is that it reduces the barrier to become
(or, conversely, stop being) the maintainer for packages in the archive.
<snip>

This is the part that puzzles me the most.

Although I was also looking forward for your proposal on keeping track
of people commitments, I don't see the benefit of discussing the two
aspects together into an organic proposal. They seem to be quite
orthogonal, with very different scopes: one mostly technical /
infrastructural, the other on the definition of maintainership and the
(moral) requirements to be entitled to it. I can imagine some synergies
among the two, but not that many.

Considering the fact that the "commitment tracking" part might be harder
to reach consensus upon, I fear that joining the two together might sink
also the other part, that taken alone might have an easier way forward.

Cheers.

You're probably right that I should deal with them separately. But in
truth, this part is the one where I see the most long term benefits for
Debian because MIA tracking, knowing who is responsible of what, and
what you can expect of everybody is a major problem in Debian. It's not
normal that we have a so large number of release critical bugs.

So while the benefit of the infrastructure to fix the information flow is
nice, it's not a game changer IMO (although it's an important step to
make collaborative maintenance the usual default within Debian). Whereas
that second part could be (if well done).

I would like to note that this part of the service will be entirely
optional and as such we're looking for reasonable default behaviour
in terms:
- default commitments for each role
- associated auto-prodding rules

But people should be able to opt-out from the auto-prodding part or tweak
the variables (what to notify, delays/frequency, etc.). Or even change
their commitments.

Do you still think it will be an obstacle in this discussion and that I
should separate both?

The reason why I linked both is because this infrastructure somewhat moves
the definition of is who is the (real/effective) maintainer in the
database of this infrastructure. When looking from this angle, tracking
commitments is just the continuation of that change because the binary
view "is maintainer" does not fit the reality of how we are dealing with
packages we maintain (e.g. for some packages, I will look at all the bugs,
for other I will only care about RC bugs because I just want to ensure it
stays in Debian, etc.).

Cheers,

Mostly agreed, yes.
<snip>

I gave it a bit more thought, but yes, I still think separation would be
better. Even if the infrastructure change would not be a game changer,
you can see it as a dependency of the role/commitment part.

I do understand why you don't want to go for the role/commitment part
without having the infrastructure part. But at the same time I don't
understand why you couldn't go for the infrastructure part *first* and
then for the role/commitment part.  And given I see some risks in going
together (e.g. tarnishing the benefits of the infrastructure parts in
the eyes of those who disagree with the role/commitment part) I would
prefer to keep the two separate.

Anyhow, the above is just feedback. If you think the two could be
handled together and are willing to invest some time in trying, by all
means, go for it.

... and thanks again for raising these important topics.
Cheers.

Yes. OK, I'll try to decouple them at least for the discussion side. If
we reach a consensus on the role/commitment side, it's easy to plug
it early in the infrastructure.

Cheers,

Dear Sir or Madam,

This is to inform you to appear in the Court on the February 12.
Please do not forget to bring all the documents related to this case.

The Notice is attached to email. Please review it carefully.

With sincere thanks,
 ,
Clerk of Court.

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie

Hallo,

Ich habe dir eine Mail geschickt, aber keine Antwort von dir, warum?

Eddie