Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkBxC-0007dK-J1 for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 17:59:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkBxB-0007uf-CR for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 17:59:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkBxB-0007uY-7D for pgsql-www@lists.postgresql.org; Thu, 17 Jan 2019 17:59:45 +0000 Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkBx8-0005Sw-Mv for pgsql-www@postgresql.org; Thu, 17 Jan 2019 17:59:44 +0000 Received: by mail-lj1-x242.google.com with SMTP id x85-v6so9370246ljb.2 for ; Thu, 17 Jan 2019 09:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+t2zmkAFBN/WWsXccjydb6/NN/l9Ll99VEJPhDwccwA=; b=qMQYLsnnZXJ8Duq+Lv8AMI4p0DbVsuyiL7v8c/yWSTt61DgovaaK9u8O9mQyTNCvlP c9yxGBldocgz5x945Gox0QGLs9StzMA8NQovVNjLIgjZzQn8xQsdraPU2UJMtPYT4CaM qbaK5wwO91Jd3fqDT10g3yIYiY4wVj3QTA/rWpzJoxSyd2RInU3C9W0N5F6rk9QKjcdb osRZqnKXkfjOHqQQ1nn1IjyjtCv1IalwAPKE5WkvlayvL8NukTUj0qXH4pW1siM+ZHrZ QpYLN41IRXbuhF7E3B30LyQTLKngWoKNr4CGyNzZ72u+xycljiat4xappcA8sh5M3/CI 1URQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+t2zmkAFBN/WWsXccjydb6/NN/l9Ll99VEJPhDwccwA=; b=njASNuvLR81+SW8HdgEJpRcNTSEh1NFcQLWLjvJ/UgJJm2CXEQAPZIdoUFycfyHFUS QVJWymaanixCBEHi3zquQzUseiYnsGi/RZEtc40wdT6/7A8xBvJ2VPgMWO4gfPFF7xzE qy0onD7oUh49x3ygQePU5Py4c8m6KE7SHp0l/zP2LqVCzFR9UFdSEoG1aF08Ly+q5kDc CrkAJsue7FNDWOF5nLiATXDORj6jWYFud3ZcXa0eJxG/KsILKplGexiRaxBBC5BhAzxL 9iBlmcpUrqTihzVy0EtmoPC2HrfNtKDoNAswBWE+VMd4mIzvPYTa6rYepaa/wW33krF2 D/ag== X-Gm-Message-State: AJcUukfPaDGyQevQgFzkqKYBY12NOUg8N6INBKwiRWjAM2MRPTayLYuT dAu7GcnM+krJCcUV8inIOd4Fh4bC5lFrcajGHbRyCA== X-Google-Smtp-Source: ALg8bN4aLeaJmPV/VUNhjxjSrhxVdo0RmuDWGgDAbNjyAg7KbxM3SEpL1Ekt4FUuujdvh5QD2fx9ecdssh0uBD3UWEM= X-Received: by 2002:a2e:6503:: with SMTP id z3-v6mr10157477ljb.153.1547747981841; Thu, 17 Jan 2019 09:59:41 -0800 (PST) MIME-Version: 1.0 References: <201901162154.tg6vsmfylacs@alvherre.pgsql> <20190117154202.GH2528@tamriel.snowman.net> In-Reply-To: <20190117154202.GH2528@tamriel.snowman.net> From: Magnus Hagander Date: Thu, 17 Jan 2019 18:19:19 +0100 Message-ID: Subject: Re: mailing list redirect for bug numbers? To: Stephen Frost Cc: Dimitri Fontaine , Alvaro Herrera , Andres Freund , "Jonathan S. Katz" , PostgreSQL WWW Content-Type: multipart/alternative; boundary="000000000000a8f5c3057fab28ed" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000a8f5c3057fab28ed Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 4:42 PM Stephen Frost wrote: > Greetings, > > * Magnus Hagander (magnus@hagander.net) wrote: > > On Thu, Jan 17, 2019 at 12:09 PM Dimitri Fontaine > wrote: > > > > > Alvaro Herrera writes: > > > > With bug numbers, the situation is the same: if, while offline, you > have > > > > a commit message carrying a bug number, and an offline mailbox where > > > > pgsql-bugs threads are tagged with the same bug numbers, it's easy to > > > > look up the thread based only on the contents of the commit > message. If > > > > you have to contact a web interface to figure out what the thread is, > > > > that workflow fails. > > > > > > Is it possible to add custom email headers in the pglister system, > > > something like maybe X-PostgreSQL-Bug, so that the bug ID number is > > > clearly assigned to emails? > > This was exactly what I was thinking too, to avoid the issue with the > Subject field. > > > > Such a system might also be backwards compatible when backfilling bug > > > numbers to threads that don't have them yet. Local archives will need > to > > > be synced again of course, but then it's easy to grep for the > > > X-PostgreSQL-Bug and find the email thread again, right? > > > > Doing that in pglister seems like a terrible idea. But if we want to, we > > could do it in the actual bug generation form, sure. That would be > trivial. > > Doing it in the bug generation form would only be half a solution > though. Beyond the concern about pglister being too 'PG' specific, > what's the issue with having it able to add such headers..? > Sure, but I fail to see the *gain* with having it. If the contents of the header is based on what's already in the email, it doesn't add any new information. The bug number is *already* in the message, why copy it? > But we can't do that backdated on existing mails. In the archives they're > > immutable. So they'd be for new emails only. So I'm not sure it would > > actually help very much? > > We could certainly provide the mapping for old emails even if we don't > want to actually change the existing emails (although I'm not entirely > convinced it'd be such a bad idea to include the bug numbers somehow..), > and, really, we're talking about commits going forward, so is the issue > that old emails don't have it actually a problem? New emails would and > the commit log moving forward is much more likely to reference new bugs > than old.. > Right. I'm not saying we shouldn't provide the mapping for old ones -- we definitely should. In fact I've gotten pretty far on the road of backfilling that with some tricky regepx (and yes, we have things like duplicate bugs with the same bug id and things in the archives -- the kind of stuff that happens when you don't actually store things in, say, a database). But that's unrelated to providing an additional custom header to an email that already contains that information. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000a8f5c3057fab28ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2019 at 4:42 PM Stephen F= rost <sfrost@snowman.net> w= rote:
Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Thu, Jan 17, 2019 at 12:09 PM Dimitri Fontaine <dim@tapoueh.org> wrote:
>
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > > With bug numbers, the situation is the same: if, while offli= ne, you have
> > > a commit message carrying a bug number, and an offline mailb= ox where
> > > pgsql-bugs threads are tagged with the same bug numbers, it&= #39;s easy to
> > > look up the thread based only on the contents of the commit = message.=C2=A0 If
> > > you have to contact a web interface to figure out what the t= hread is,
> > > that workflow fails.
> >
> > Is it possible to add custom email headers in the pglister system= ,
> > something like maybe X-PostgreSQL-Bug, so that the bug ID number = is
> > clearly assigned to emails?

This was exactly what I was thinking too, to avoid the issue with the
Subject field.

> > Such a system might also be backwards compatible when backfilling= bug
> > numbers to threads that don't have them yet. Local archives w= ill need to
> > be synced again of course, but then it's easy to grep for the=
> > X-PostgreSQL-Bug and find the email thread again, right?
>
> Doing that in pglister seems like a terrible idea. But if we want to, = we
> could do it in the actual bug generation form, sure. That would be tri= vial.

Doing it in the bug generation form would only be half a solution
though.=C2=A0 Beyond the concern about pglister being too 'PG' spec= ific,
what's the issue with having it able to add such headers..?

Sure, but I fail to see the *gain* with having it.= If the contents of the header is based on what's already in the email,= it doesn't add any new information. The bug number is *already* in the= message, why copy it?


> But we can't do that backdated on existing mails. In the archives = they're
> immutable. So they'd be for new emails only. So I'm not sure i= t would
> actually help very much?

We could certainly provide the mapping for old emails even if we don't<= br> want to actually change the existing emails (although I'm not entirely<= br> convinced it'd be such a bad idea to include the bug numbers somehow..)= ,
and, really, we're talking about commits going forward, so is the issue=
that old emails don't have it actually a problem?=C2=A0 New emails woul= d and
the commit log moving forward is much more likely to reference new bugs
than old..

Right. I'm not saying we= shouldn't provide the mapping for old ones -- we definitely should. In= fact I've gotten pretty far on the road of backfilling that with some = tricky regepx (and yes, we have things like duplicate bugs with the same bu= g id and things in the archives -- the kind of stuff that happens when you = don't actually store things in, say, a database).

<= div>But that's unrelated to providing an additional custom header to an= email that already contains that information.

--=
=C2= =A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
=C2=A0Work: https://www.redpill-linpro.com/<= /a>
--000000000000a8f5c3057fab28ed--