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 1gkCdN-0001Lm-S4 for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 18:43:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gkCdM-0000aT-NG for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 18:43:20 +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 1gkCdM-0000Wy-HG for pgsql-www@lists.postgresql.org; Thu, 17 Jan 2019 18:43:20 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gkCdK-0006X5-1s for pgsql-www@postgresql.org; Thu, 17 Jan 2019 18:43:20 +0000 Received: by mail-lf1-x131.google.com with SMTP id c16so8585605lfj.8 for ; Thu, 17 Jan 2019 10:43:17 -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=zVuECJOmR16xJYifs03pIJDRBMc180ULlbR2IHrbVk4=; b=IqT2Lel3CpApa7dU/XFXveAEugOJaEqpP80WilUktK3JcpMxBFRkaoogDEcK7SrGek fEdDugBpUeCR1oBvXOkjuJXOUZqYEZ6rqeS4azG0iHvBOVwdmJrXHDDhDaVLP86jc6u6 /Xd6KN9BvaIRAsAg/E2t+8EFVQt+BgJL3ia+vxLBzyfgvlyvuy272hhNa5OShRrkeYsw 4BxChLCq7Up4sVtTwMX4vPFB0azkQzkZNnMSFX8XIWanRRz5/LnjsWODHv7dy25cEhNL hDWXGWJ0Lzy4TYjV71ZFer9SHtF/uGwV434DNhWZKq1Jr0dNWJFx7fsBMgGCav1wuWxF RYJQ== 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=zVuECJOmR16xJYifs03pIJDRBMc180ULlbR2IHrbVk4=; b=b55Z/GXmHuOonhDFtNJvXL+0/+m/s2pIjZBCTM2dtnnpwbJ7A9TxfveTeYwG0Qdt8D BJFybgPCZ8jr+qYHLfA8ynT7EQUwwMkhXr2kW1ezZIyXpjrwcVSe6zlBMNFyqT0pI0VE LxOQ64dqWh180NPsjFC96b5jlUvLt3c3GogQqRDV+Q02B+2fZ2OIgCiRuLL0jV+KPlrb zA0ZQMDWAOkGtQPuLptUXXYtL0zkk/wIkGPMQCeGVWCmqMPzzjOzrj/QV0YNhwGLcOL0 Klk2THxla829sMfhyGKIEV7ge/G2A7+Xy7B6MwgOo+eQOkY0Sx2Q+ClrDD3Ow/+H2bLo w49w== X-Gm-Message-State: AJcUukcTCRaC6xUSBQ8RrVVtHSve9SIzyRPNqDIvgDbiN19aHVTJLCAZ NKNfVvs/7wAT+8TuuZV4MQE7/zrafexuPF0NSvsdqA== X-Google-Smtp-Source: ALg8bN6PWjhg8m/41tjqmhPwamcEAqV8I0OpIrZg67UCyP0xuf0Lo/Oos7x654PO28nP/dL25N21D4QaA2MOJQE1+mU= X-Received: by 2002:a19:8f45:: with SMTP id r66mr11618320lfd.9.1547750595846; Thu, 17 Jan 2019 10:43:15 -0800 (PST) MIME-Version: 1.0 References: <201901162154.tg6vsmfylacs@alvherre.pgsql> <20190117154202.GH2528@tamriel.snowman.net> <20190117182821.GK2528@tamriel.snowman.net> In-Reply-To: <20190117182821.GK2528@tamriel.snowman.net> From: Magnus Hagander Date: Thu, 17 Jan 2019 19:43:04 +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="000000000000778243057fabc4f3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000778243057fabc4f3 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 7:28 PM Stephen Frost wrote: > Greetings, > > * Magnus Hagander (magnus@hagander.net) wrote: > > On Thu, Jan 17, 2019 at 4:42 PM Stephen Frost > wrote: > > > > 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? > > Uhhh, no, the point here was to assign bug numbers for emails to -bugs > which *don't* go through the bugs form and therefore didn't have the bug > number info in the message. > Without having the ability to properly merge bugs and to structured cross referencing and such, I think that's a really bad idea. That's going to cause more problems than it's fixing. > > Doing it for the ones that *did* go through the form might be nice > because it'd add consistency as to where to find the bug number and that > could possibly even be done across replies that might have changed the > Subject line and removed the bug and such. > Eh. AFAIK there is no way to add a header that MUAs making replies are going to add to the reply as well. Our one chance to thread together emails are in the References headers, which is what the archives do today. A header like this would have zero effect on that. It *is* consistent where to find the bug number. The only differences we've done in the past 20 years are change from "Bug" to "BUG" and add a : after the number.... > > 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. > > For emails from the bugs form, having the bug number in a header > (instead of just the subject) seems like it could be independently > useful, but the discussion here was about providing a way for bug > numbers to be assigned based on just an inbound email- one that didn't > use the form. > Doing that at the form addition is trivial, and if people think it's useful I'll be happy to add that. I just don't see how it would be useful, but if others do.. And no, the issue here was to redirect from bug numbers to the archives. Everything else is scope creep :P -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000778243057fabc4f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2019 at 7:28 PM Stephen F= rost <sfrost@snowman.net> w= rote:
Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Thu, Jan 17, 2019 at 4:42 PM Stephen Frost <sfrost@snowman.net> wrote:
> > > 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 wo= uld be
> > trivial.
> >
> > Doing it in the bug generation form would only be half a solution=
> > though.=C2=A0 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?<= br>
Uhhh, no, the point here was to assign bug numbers for emails to -bugs
which *don't* go through the bugs form and therefore didn't have th= e bug
number info in the message.


<= div>Without having the ability to properly merge bugs and to structured cro= ss referencing and such, I think that's a really bad idea. That's g= oing to cause more problems than it's fixing.

=C2=A0

Doing it for the ones that *did* go through the form might be nice
because it'd add consistency as to where to find the bug number and tha= t
could possibly even be done across replies that might have changed the
Subject line and removed the bug and such.

<= div>Eh. AFAIK there is no way to add a header that MUAs making replies are = going to add to the reply as well.

Our one chance = to thread together emails are in the References headers, which is what the = archives do today. A header like this would have zero effect on that.
=

It *is* consistent where to find the bug number. The on= ly differences we've done in the past 20 years are change from "Bu= g" to "BUG" and add a : after the number....

<= /div>

> > But we can't do that backdated on existing mails. In the arch= ives 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?=C2=A0 New e= mails would and
> > the commit log moving forward is much more likely to reference ne= w 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 a= n email
> that already contains that information.

For emails from the bugs form, having the bug number in a header
(instead of just the subject) seems like it could be independently
useful, but the discussion here was about providing a way for bug
numbers to be assigned based on just an inbound email- one that didn't<= br> use the form.


Doing that= at the form addition is trivial, and if people think it's useful I'= ;ll be happy to add that. I just don't see how it would be useful, but = if others do..=C2=A0

And no, the issue here = was to redirect from bug numbers to the archives. Everything else is scope = creep :P

--
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
= =C2=A0Work: ht= tps://www.redpill-linpro.com/
--000000000000778243057fabc4f3--