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 1gjMSJ-0001I5-Jf for pgsql-www@arkaria.postgresql.org; Tue, 15 Jan 2019 11:00:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gjMSI-00059v-7J for pgsql-www@arkaria.postgresql.org; Tue, 15 Jan 2019 11:00:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjMSH-00059o-Js for pgsql-www@lists.postgresql.org; Tue, 15 Jan 2019 11:00:25 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjMS9-0007Rf-Ff for pgsql-www@postgresql.org; Tue, 15 Jan 2019 11:00:24 +0000 Received: by mail-lf1-x12d.google.com with SMTP id a16so1705803lfg.3 for ; Tue, 15 Jan 2019 03:00: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=38QJfkp81r36vcs+BX7wLF2Rk/33axHF7YK+++A+iyA=; b=T+WPEPz100puGNxWteLuTtHq4Wt6HY4SP/aNIHxTqYFYZkcAjjSAoFHbtxcPwHMY+J FjpzrBbJpsK0rF4oog7UTuLwviEpmJ+DKltwJSS7wxPBXo8sHzET33MFt8Cj3Ufu1uau u5P7b1GoCaskpoD7aXgrUKlaan6DkZd4yIEPe3TaS1khSWNvTtpyOnBrB9oNvCN2bv4+ SblFsBHHanRnZgWloyx8LUYuOEAagkpRu8UUMv1KBnxvOL6J5hI59e1+/mPWYKovSssO G5fGcYEvVI+GhyJIyCSpPQlqfLUAfZs0pvZn+w8iSclSbXdta3mur3Wp2HkUduCrv95H ZmEA== 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=38QJfkp81r36vcs+BX7wLF2Rk/33axHF7YK+++A+iyA=; b=t3/virIk+xS01U4Yhud1QMXosUFQ1bJCjCiSjuD2VL9MvQSULlJCXvd091SgvUK4Cz T6bullBIWN4qppPUfAHHwQ0n5dWc605Wg3x41s8aiGwQRxqwHq9WghyHjKhJjAN4cY9h 20pXFmF7wnCPsFm5TdU+KlDpncQMUvnaAMaDdpQFTmnuY3nTuEuElo3GaGVNOpurHzbA nGQn4Sz+FZxWjuIZTcdOHwTaRUt+kfKARgHAIZknHCmzCEIV/x9wl2Xaql5Opdk4IPLU 0Jp1xusxvHc+TKKSYlIh1J+/8OT0LTaRWclZ4AmrdtcGX2KXFk6k82ExCxBY7c+o3wQT Eidg== X-Gm-Message-State: AJcUukdnUOACfUW2onIw2cNYMf+0b8+DQdBMy4B1WWjvPjg+aUiMn4+L rveS80kyQvse58ml51LwFNy0IvZkedJ4l9fc4x4aDg== X-Google-Smtp-Source: ALg8bN73GY0D7XVEymvnWltEIrJxIzkcwiSuJvwOZ5Gg4HHO3T6lgiFHoiCG34TBg60GUKfwVI/lr/kFZhnKI50ANZY= X-Received: by 2002:a19:3b9c:: with SMTP id d28mr2516316lfl.30.1547550015703; Tue, 15 Jan 2019 03:00:15 -0800 (PST) MIME-Version: 1.0 References: <20190114221809.eymqah36d6uq5nir@alap3.anarazel.de> <9cfc2880-0623-7cc3-45f4-342c3af881fe@postgresql.org> In-Reply-To: From: Magnus Hagander Date: Tue, 15 Jan 2019 12:00:04 +0100 Message-ID: Subject: Re: mailing list redirect for bug numbers? To: "Jonathan S. Katz" Cc: Andres Freund , PostgreSQL WWW Content-Type: multipart/alternative; boundary="000000000000f5653f057f7d109b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000f5653f057f7d109b Content-Type: text/plain; charset="UTF-8" On Tue, Jan 15, 2019 at 11:57 AM Magnus Hagander wrote: > On Tue, Jan 15, 2019 at 11:43 AM Jonathan S. Katz > wrote: > >> Hi Andres, >> >> On 1/14/19 5:18 PM, Andres Freund wrote: >> > Hi, >> > >> > How hard would it be to have a redirect similar to >> > https://www.postgresql.org/message-id/ >> > >> > that accepted bug numbers instead of message ids? I don't know the >> > precise database schema of the archives, but I assume it could be done >> > with a prefix query that filters the sender to @postgresql.org, the >> list >> > to pgsql-bugs, and the prefix to "BUG #" or such. >> >> The bug ID numbers are generated from pgweb using: >> >> SELECT nextval('bug_id_seq') >> >> And then prefixed to the email thread as per the above. >> > > Worth noticing is that it's also prefixed to the message-id, but that's a > fairly new thing. > > > More on this in a second. >> >> > Or perhaps >> > there's a database table with bugs -> messageid mappings somewhere? Or >> > could be created using a query like the above? >> >> IMV that would be an excellent suggestion. My guess is in order to make >> that work, we would create the mapping when the initial bug report makes >> it into the archives. > > >> > It'd be neat to link to bugs from commit messages in a clearer format >> > (i.e. to the bug number, rather than it being one of potentially >> > multiple message ids), and it also makes manual lookup nicer. >> >> Agreed, that sounds like a nicer UX. >> > Oh, and I missed saying -- +1 for the idea in general, it definitely sounds useful. The only big catch I see is that if someone emails -bugs directly, no >> number is assigned, so we would have to leave that be. >> > > Yeah, those would be entirely out of scope. > > > I don't know if we would want to use "/message-id/" as the parent URL, >> just in case someone sent a message with an ID of just digits (for >> whatever reason). Dare I suggest something like "/bugs//? >> > > Or would we perhaps want tp use the postgr.es urls-shorterner with just a > /b/ (like we have /m/ for messageids)? > > > >> Assuming buy-in, what would need to be done is: >> >> - Adjust the message import script to parse inbound messages with above >> message beginning to -bugs. Determine if it is the first message to the >> thread / bug ID is already registered. If it does not exist, record the >> bug ID, message ID combo in a new table >> > > That would suddenly put a very hard coded assumption into the archives > code about this format, which I think is a bad idea in general since the > archives code is not specific to the pgsql list usage *at all* today.... > > > - Write a one time script to map old bug id to first message id in the >> thread. >> >> - Update the urls.py in pgarchives to handle said route and fail >> gracefully if bug ID does not exist >> >> - Note in pgweb where the email is generated that any changes to email >> subject could break things. >> >> And that should be that. >> > > I think it would be easier to just have a simple piece of lookup code that > has access to the archives db. When fed a bug number, it first looks for a > messageid according to the new format messageid, and if its found (and just > one) then redirect to that. If not, then to a subject prefix search and > validate that the messageid is one that does match what it should do (e.g. > that it comes from the correct servers -- there haven't been many so far, > so it's easy to construct a whitelist) and returns exactly one, then > redirect to that, otherwise 404. > > The difficulty in all those is we don't currently index the subject other > than as part of the full text. But that can probably be added pretty > cheaply. > > -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000f5653f057f7d109b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 15, 2019 at 11:57 AM Magnus H= agander <magnus@hagander.net&= gt; wrote:
On Tue, Jan 15, 201= 9 at 11:43 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
Hi Andre= s,

On 1/14/19 5:18 PM, Andres Freund wrote:
> Hi,
>
> How hard would it be to have a redirect similar to
> https://www.postgresql.org/message-id/<id>
>
> that accepted bug numbers instead of message ids?=C2=A0 I don't kn= ow the
> precise database schema of the archives, but I assume it could be done=
> with a prefix query that filters the sender to @postgresql.org, the li= st
> to pgsql-bugs, and the prefix to "BUG #<bugno>" or suc= h.

The bug ID numbers are generated from pgweb using:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SELECT nextval('bug_id_seq')

And then prefixed to the email thread as per the above.

Worth noticing is that it's also prefixed to the messa= ge-id, but that's a fairly new thing.


More on this in a second.

> Or perhaps
> there's a database table with bugs -> messageid mappings somewh= ere? Or
> could be created using a query like the above?

IMV that would be an excellent suggestion. My guess is in order to make
that work, we would create the mapping when the initial bug report makes it into the archives.=C2=A0

> It'd be neat to link to bugs from commit messages in a clearer for= mat
> (i.e. to the bug number, rather than it being one of potentially
> multiple message ids), and it also makes manual lookup nicer.

Agreed, that sounds like a nicer UX.

Oh, and I missed saying --=C2=A0+1 for the idea in g= eneral, it definitely sounds useful.


The only big catch I see is that if someone emails -bugs directly, no
number is assigned, so we would have to leave that be.

Yeah, those would be entirely out of scope.

<= /div>

I don't know if we would want to use "/message-id/" as the pa= rent URL,
just in case someone sent a message with an ID of just digits (for
whatever reason). Dare I suggest something like "/bugs/<id>/?

Or would we perhaps want tp use the postgr.es urls-shorterner wit= h just a /b/ (like we have /m/ for messageids)?=C2=A0

<= div>=C2=A0
Assuming buy-in, what would need to be done is:

- Adjust the message import script to parse inbound messages with above
message beginning to -bugs. Determine if it is the first message to the
thread / bug ID is already registered. If it does not exist, record the
bug ID, message ID combo in a new table

That would suddenly put a very hard coded assumption into the archives cod= e about this format, which I think is a bad idea in general since the archi= ves code is not specific to the pgsql list usage *at all* today....


- Write a one time script to map old bug id to first message id in the
thread.

- Update the urls.py in pgarchives to handle said route and fail
gracefully if bug ID does not exist

- Note in pgweb where the email is generated that any changes to email
subject could break things.

And that should be that.

I think it wou= ld be easier to just have a simple piece of lookup code that has access to = the archives db. When fed a bug number, it first looks for a messageid acco= rding to the new format messageid, and if its found (and just one) then red= irect to that. If not, then to a subject prefix search and validate that th= e messageid is one that does match what it should do (e.g. that it comes fr= om the correct servers -- there haven't been many so far, so it's e= asy to construct a whitelist) and returns exactly one, then redirect to tha= t, otherwise 404.

The difficulty in all those is w= e don't currently index the subject other than as part of the full text= . But that can probably be added pretty cheaply.
=C2=A0

--
=C2=A0Magnus Hagander
=C2=A0Me: <= a href=3D"http://www.hagander.net/" target=3D"_blank">https://www.hagander.= net/
=C2=A0Work: https://www.redpill-linpro.com/
--000000000000f5653f057f7d109b--