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 1gk43q-0000zL-I3 for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 09:34:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gk43p-0004Or-6D for pgsql-www@arkaria.postgresql.org; Thu, 17 Jan 2019 09:34:05 +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 1gk43p-0004Oj-0c for pgsql-www@lists.postgresql.org; Thu, 17 Jan 2019 09:34:05 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gk43l-0002G5-VJ for pgsql-www@postgresql.org; Thu, 17 Jan 2019 09:34:04 +0000 Received: by mail-lf1-x144.google.com with SMTP id p6so7277424lfc.1 for ; Thu, 17 Jan 2019 01:34:01 -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=fWSNOqRcEui3fTyKi+YVDiV+Ygaivq2FS2VYkIITEBM=; b=zA+Y4Yqc0FDdIXPsjLK64rbI+jdTJC7hBrsQLi5yF42LJvKD5QENIzcR63aOQlnNOQ r/hqJQ0fmBqb0RyzJwp8wwWCK5ASuJov4ZCCzGKxPi0CQmRhhWdFP/dpCw2z6S/udj22 6QNL0V3NarRu7FgeefRFDYgWPDY3+7s8YdgekDvF+cisQFBwbgy5ASttkNMnIvbgqYHr 1klIog8RkgDC6Dx0Ka4Sg+Y/0Dw9QdCNyQZrMCQ53NK35n77eBqjtSUMJfxBo/yjdqfv DbJpKcWYl1nvLdU38nlHT0FMLUFcyzxi0da3sv0BcDuDAM9UdKKT9n0Jg0qzXnf/6aSd ts/Q== 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=fWSNOqRcEui3fTyKi+YVDiV+Ygaivq2FS2VYkIITEBM=; b=KqvhjRV6764d87yygwCu7nCfSiRtbCwsCAdk4HJoEIlZtDYgrsixUVD5tyZ+7cjyVc GOPhlILvU+cv0UJ9yWGtwfq4Z45oc3s4rWrZuzBflCSHAtTnoGbXJJRn3OaF63/ZG4+Q NH8YqZzFn7KY+ZtYAAhKiESBQPoap37mSgjSv+cSu656cKc1YVVi0bDu5VPryD/OITXm CIWeRHX3SyIu4apnyRuEXHWhqig83zNK8F2WZOBDYmvDkQ3HFCA19AxdC4dt+i6ymVoE rNwdFieCW4b5JestmrYR2Qf5uWxKa6FTgdVqkBx1//FxcQgeqgO7liQYrAjmbkMQjOwU tBcA== X-Gm-Message-State: AJcUukdROU27KndCRBnRXqRLM0gWEN64NRtsZtfOk7pId/N1V8dfzBlE nIvvHLEK2jvsDrS+gzHv20h12Q8iVVnrl+6ajk6xAg== X-Google-Smtp-Source: ALg8bN6Ai8qekOyXeUBkc55KVq4JdVikzuBhD3nCDvvq2gx3MENH+UJC2iPtesDaO8qCEKRloWrtgQHLWAxKQifVU5A= X-Received: by 2002:a19:5e5d:: with SMTP id z29mr9533378lfi.105.1547717640307; Thu, 17 Jan 2019 01:34:00 -0800 (PST) MIME-Version: 1.0 References: <20190116195327.GF2528@tamriel.snowman.net> <201901162154.tg6vsmfylacs@alvherre.pgsql> <20190116215607.3bfswn4syewmncix@alap3.anarazel.de> In-Reply-To: <20190116215607.3bfswn4syewmncix@alap3.anarazel.de> From: Magnus Hagander Date: Thu, 17 Jan 2019 10:33:49 +0100 Message-ID: Subject: Re: mailing list redirect for bug numbers? To: Andres Freund Cc: Alvaro Herrera , Stephen Frost , "Jonathan S. Katz" , PostgreSQL WWW Content-Type: multipart/alternative; boundary="00000000000029f00c057fa418a1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000029f00c057fa418a1 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 16, 2019 at 10:56 PM Andres Freund wrote: > On 2019-01-16 18:54:40 -0300, Alvaro Herrera wrote: > > On 2019-Jan-16, Stephen Frost wrote: > > > > > As I recall, we actively discussed doing something similar for > -hackers, > > > to shorten up the URLs going into commit messages but there was some > > > concern over having a mapping from IDs to message-IDs. I'd have to go > > > dig up the thread to remember what the issue was there. > > > > The issue is that people working offline want to be able to figure out > > emails in their local mailboxes looking just at the contents of a commit > > message. This is trivial if the URLs contain the message-id, and > > impossible if they don't. > > > > 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. > > > > Based on this, my opinion is that a redirection system that handles > > https://postgr.es/bug/8470 > > by redirecting to message > > https://postgr.es/m/E1VOpEt-0003nc-4J@wrigleys.postgresql.org > > works fine, because I can look up the thread by looking for the bug > > number in the subject. If we do anything more complicated than that > > (say a database filled with message-ids based on bug IDs that don't > > appear in the message subject), that workflow fails when I'm offline. > > Well said. > Definitely agreed. The current bug assignment system is trivial for a reason, let's keep it that way. If what we want is a bugtracker we should have that instead, but hey, that's definitely out of scope and let's not open that can of worms today. I've added a patch to start tracking the bugid<->messageid mapping on new bugs. There's no using it yet, but at least we track for the future. Next step is backfill, and after that we can start stitching the pieces together. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --00000000000029f00c057fa418a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 16, 2019 at 10:56 PM Andres F= reund <andres@anarazel.de> = wrote:
On 2019-01-16 18:54:40 -0300, Alvaro Herrera wrote:
> On 2019-Jan-16, Stephen Frost wrote:
>
> > As I recall, we actively discussed doing something similar for -h= ackers,
> > to shorten up the URLs going into commit messages but there was s= ome
> > concern over having a mapping from IDs to message-IDs.=C2=A0 I= 9;d have to go
> > dig up the thread to remember what the issue was there.
>
> The issue is that people working offline want to be able to figure out=
> emails in their local mailboxes looking just at the contents of a comm= it
> message.=C2=A0 This is trivial if the URLs contain the message-id, and=
> impossible if they don't.
>
> With bug numbers, the situation is the same: if, while offline, you ha= ve
> 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.= =C2=A0 If
> you have to contact a web interface to figure out what the thread is,<= br> > that workflow fails.
>
> Based on this, my opinion is that a redirection system that handles >=C2=A0 =C2=A0https://postgr.es/bug/8470
> by redirecting to message
>=C2=A0 =C2=A0https://postgr.es/m/E1= VOpEt-0003nc-4J@wrigleys.postgresql.org
> works fine, because I can look up the thread by looking for the bug > number in the subject.=C2=A0 If we do anything more complicated than t= hat
> (say a database filled with message-ids based on bug IDs that don'= t
> appear in the message subject), that workflow fails when I'm offli= ne.

Well said.

Definitely agreed. The current bug a= ssignment system is trivial for a reason, let's keep it that way. If wh= at we want is a bugtracker we should have that instead, but hey, that's= definitely out of scope and let's not open that can of worms today.

I've added a patch to start tracking the bugid&l= t;->messageid mapping on new bugs. There's no using it yet, but at l= east we track for the future. Next step is backfill, and after that we can = start stitching the pieces together.

--
=C2=A0Magnus Hagander=
=C2=A0Me: https:= //www.hagander.net/
=C2=A0Work: https://www.redpill-linpro.com/
--00000000000029f00c057fa418a1--