Re: Mail thread references in commits

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Joshua Drake <jd(at)commandprompt(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Mail thread references in commits
Date: 2016-11-30 14:52:32
Message-ID: 16a18db5-6980-1142-153d-37e1d3ad8ee2@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/27/16 8:37 AM, Magnus Hagander wrote:
> Ok, we now have it. https://postgr.es/m/messageid will redirect to that
> messageid in the main archives.

I like the idea of recording the location of the discussion, but I'm not
fond of the URL shortener. Besides the general problem that URL
shortening looks ugly and fake, it fragments the way we address things.
Ideally, message IDs should tie together our main development tools:
email, commit fest app, web site, and commits. If we use different
addresses in each of them, it will be confusing and harder to tie things
together. For example, I would ideally like to just paste the thread
URL from the commit fest app into the commit message. If I have to
manually shorten the URL, then that is error prone and less interesting
to do. Also, the commit fest app links to a thread, not a message.
Another concern is how search engines will process this.

Do we know of an actual length limit that is useful to aim for? If we
just make it just a bit shorter but it's still too long for a large
class of email readers, depending on the message ID format, then it's
not that useful.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-11-30 15:21:37 Re: patch: function xmltable
Previous Message Peter Eisentraut 2016-11-30 14:43:49 Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows