Обсуждение: Mail thread references in commits
I love seeing references to email threads in commit messages. It would make them a lot friendlier though if a full http URL were included instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put <https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is a bit more trouble. but not that much, and it would make it very easy to follow with just a mouse click. cheers andrew
On November 17, 2016 1:02:38 PM PST, Andrew Dunstan <andrew@dunslane.net> wrote: >I love seeing references to email threads in commit messages. It would >make them a lot friendlier though if a full http URL were included >instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put ><https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is > >a bit more trouble. but not that much, and it would make it very easy >to >follow with just a mouse click. They're really hard to read though, because lines with e.g. gmail message IDs get very long even without that prefix. Doyou look at these in the e-mail or gitweb? Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thu, Nov 17, 2016 at 4:06 PM, Andres Freund <andres@anarazel.de> wrote: > On November 17, 2016 1:02:38 PM PST, Andrew Dunstan <andrew@dunslane.net> wrote: >>I love seeing references to email threads in commit messages. It would >>make them a lot friendlier though if a full http URL were included >>instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put >><https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is >> >>a bit more trouble. but not that much, and it would make it very easy >>to >>follow with just a mouse click. > > They're really hard to read though, because lines with e.g. gmail message IDs get very long even without that prefix. Do you look at these in the e-mail or gitweb? Yeah. I really hate having commit messages that are more than 70-75 characters wide, and a message-ID takes you well above that. I wish we had something like archives.postgresql.org/sha/5bcd5142 instead of basing everything off the message-ID. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Andrew Dunstan wrote: > I love seeing references to email threads in commit messages. It would make > them a lot friendlier though if a full http URL were included instead of > just a Message-ID, i.e. instead of <foo1234@bar.com> put > <https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is a > bit more trouble. but not that much, and it would make it very easy to > follow with just a mouse click. I completely agree. I would favor something even more convenient, such as https://postgr.es/m/foo1234@bar.com which just redirects to the full URL. That saves a decent number of chars. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Robert Haas wrote: > On Thu, Nov 17, 2016 at 4:06 PM, Andres Freund <andres@anarazel.de> wrote: > > On November 17, 2016 1:02:38 PM PST, Andrew Dunstan <andrew@dunslane.net> wrote: > >>I love seeing references to email threads in commit messages. It would > >>make them a lot friendlier though if a full http URL were included > >>instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put > >><https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is > >> > >>a bit more trouble. but not that much, and it would make it very easy > >>to > >>follow with just a mouse click. > > > > They're really hard to read though, because lines with e.g. gmail message IDs get very long even without that prefix. Do you look at these in the e-mail or gitweb? > > Yeah. I really hate having commit messages that are more than 70-75 > characters wide, and a message-ID takes you well above that. I wish > we had something like archives.postgresql.org/sha/5bcd5142 instead of > basing everything off the message-ID. The advantage of using the message-ID is that you can use it while offline too (very common among this crowd to do stuff while on planes, since conferences and such are so frequent now), so I wouldn't make that trade. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew@dunslane.net> writes: > I love seeing references to email threads in commit messages. It would > make them a lot friendlier though if a full http URL were included > instead of just a Message-ID, I've intentionally not done that, because it does not seem very future-proof. The message ids will hopefully be unique indefinitely far into the future, but the location of our archives could move. Andres' point about line length is also an issue. FWIW, I have my home page set up so that I can paste in a message ID and go directly to the archived thread; there's more than one way to skin that cat. regards, tom lane
On 11/17/2016 04:06 PM, Andres Freund wrote: > > On November 17, 2016 1:02:38 PM PST, Andrew Dunstan <andrew@dunslane.net> wrote: >> I love seeing references to email threads in commit messages. It would >> make them a lot friendlier though if a full http URL were included >> instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put >> <https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is >> >> a bit more trouble. but not that much, and it would make it very easy >> to >> follow with just a mouse click. > They're really hard to read though, because lines with e.g. gmail message IDs get very long even without that prefix. Do you look at these in the e-mail or gitweb? > Mainly in Thunderbird. But it's cumbersome either way. I agree gmail message IDs are ugly and insanely long. Personally I would rather pay the price of one line of ugliness for nice clickability. To Tom's point that the URL might be ephemeral while the Message-ID is not, the URL would contain the Message-ID, so even if the base changed you could adjust to it. cheers andrew **
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > I love seeing references to email threads in commit messages. It would > > make them a lot friendlier though if a full http URL were included > > instead of just a Message-ID, > > I've intentionally not done that, because it does not seem very > future-proof. The message ids will hopefully be unique indefinitely far > into the future, but the location of our archives could move. It won't. We have far too many in the archives to risk breaking them. In fact, we (Magnus) went great lengths to implement a system so that old-style PHP links (of which we have a bunch in very old archives, including in commit messages) continue to work to this day. We're far too invested in the system now, because of how successful it has proved to be. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
<p dir="ltr">Why not hash the URL? Something like:<p dir="ltr"><a href="Http://postgresopen.org/archive/743257890976432">Http://postgresopen.org/archive/743257890976432</a><p dir="ltr">Wherethe hash is derived from the message if?<p dir="ltr">On Nov 17, 2016 17:40, "Alvaro Herrera" <<a href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>wrote:<br /> ><br /> > Tom Lane wrote:<br />> > Andrew Dunstan <<a href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>> writes:<br /> > > >I love seeing references to email threads in commit messages. It would<br /> > > > make them a lot friendlierthough if a full http URL were included<br /> > > > instead of just a Message-ID,<br /> > ><br />> > I've intentionally not done that, because it does not seem very<br /> > > future-proof. The message idswill hopefully be unique indefinitely far<br /> > > into the future, but the location of our archives could move.<br/> ><br /> > It won't. We have far too many in the archives to risk breaking them.<br /> > In fact, we(Magnus) went great lengths to implement a system so that<br /> > old-style PHP links (of which we have a bunch in veryold archives,<br /> > including in commit messages) continue to work to this day. We're far<br /> > too investedin the system now, because of how successful it has proved<br /> > to be.<br /> ><br /> > --<br /> >Álvaro Herrera <a href="https://www.2ndQuadrant.com/">https://www.2ndQuadrant.com/</a><br /> > PostgreSQLDevelopment, 24x7 Support, Remote DBA, Training & Services<br /> ><br /> ><br /> > --<br /> > Sentvia pgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br />> To make changes to your subscription:<br /> > <a href="http://www.postgresql.org/mailpref/pgsql-hackers">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/>
On Fri, Nov 18, 2016 at 1:38 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >> > I love seeing references to email threads in commit messages. It would >> > make them a lot friendlier though if a full http URL were included >> > instead of just a Message-ID, >> >> I've intentionally not done that, because it does not seem very >> future-proof. The message ids will hopefully be unique indefinitely far >> into the future, but the location of our archives could move. > > It won't. We have far too many in the archives to risk breaking them. > In fact, we (Magnus) went great lengths to implement a system so that > old-style PHP links (of which we have a bunch in very old archives, > including in commit messages) continue to work to this day. We're far > too invested in the system now, because of how successful it has proved > to be. Right - we go out of our way to ensure we don't break URLs. That's why anoncvs.postgresql.org is still actively maintained for example. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake <jd@commandprompt.com> wrote: > Why not hash the URL? Something like: > > Http://postgresopen.org/archive/743257890976432 I suggested that upthread... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
<p dir="ltr">Sorry didn't see it. <div class="gmail_extra"><br /><div class="gmail_quote">On Nov 18, 2016 12:44, "RobertHaas" <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br type="attribution" /><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 17, 2016at 10:43 PM, Joshua Drake <<a href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>> wrote:<br /> > Whynot hash the URL? Something like:<br /> ><br /> > <a href="Http://postgresopen.org/archive/743257890976432" rel="noreferrer"target="_blank">Http://postgresopen.org/<wbr />archive/743257890976432</a><br /><br /> I suggested that upthread...<br/><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a href="http://www.enterprisedb.com" rel="noreferrer" target="_blank">http://www.enterprisedb.com</a><br/> The Enterprise PostgreSQL Company<br /></blockquote></div></div>
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake <jd@commandprompt.com> wrote: >> Why not hash the URL? Something like: >> Http://postgresopen.org/archive/743257890976432 > I suggested that upthread... Don't like the hashing idea because that would be useless for searching, eg, one's own local mail archives. Also, if you are looking at a message in your own mail store when composing a commit message (which I generally am, don't know about other committers) how are you going to get the hash? I think it's important to have the message-ID in cleartext. AFAICS the proposal here is to go from, eg, Discussion: <CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com> to Discussion: https://www.postgresql.org/message-id/CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com which is annoying, but the line was overlength already. Maybe we could drop the Discussion: prefix and just write a URL: https://www.postgresql.org/message-id/CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com That's still overlength for gmail message-IDs, though, so I'm not sure it's worth losing the label for. regards, tom lane
Tom Lane wrote: > AFAICS the proposal here is to go from, eg, > > Discussion: <CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com> > > to > > Discussion: https://www.postgresql.org/message-id/CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com > > which is annoying, but the line was overlength already. Maybe we could > drop the Discussion: prefix and just write a URL: > > https://www.postgresql.org/message-id/CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com If we use our existing URL shortener, as I proposed upthread, it's still overlength but decent enough: https://postgr.es/m/CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com I was pretty sure I had proposed this previously and was surprised that I couldn't find it in the archives anywhere; and sure enough, what I did was post the idea to sysadmins@postgresql.org (over a year ago) so it wasn't publicly visible. Anyway, I think the shortener is worth using (and we can certainly spare the namespace). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Nov 18, 2016 at 11:08 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Tom Lane wrote:
> AFAICS the proposal here is to go from, eg,
>
> Discussion: <CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@mail.gmail.com>
>
> to
>
> Discussion: https://www.postgresql.org/message-id/CAF4Au4w6rrH_ j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@mail.gmail.com
>
> which is annoying, but the line was overlength already. Maybe we could
> drop the Discussion: prefix and just write a URL:
>
> https://www.postgresql.org/message-id/CAF4Au4w6rrH_ j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@mail.gmail.com
If we use our existing URL shortener, as I proposed upthread, it's still
overlength but decent enough:
https://postgr.es/m/CAF4Au4w6rrH_ j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@mail.gmail.com
It does cut it down a bit. And doing it that way would certainly make it very "long term survivable". If we put a hash in there, we have to store the hash somewhere. Not that this is hard, but if there is concern about long-termability.
Another option would be to teach the URL shortener about our messages specifically, and just use an internal surrogate key we already have for them. That way it could be something like the current Planet URLs (which can be for example http://postgr.es/p/3Dl), so much shorter. To post one people would have to go to a webform and paste in the messageid or existing URL though -- or we could put a link on the page in the archives.
It would make the URLs actually short, but as mentioned upthread, that wouldn't work at all if offline. So it'd be a tradeoff between those, but so are pretty much all other options that don't include the full message-id.
Magnus, * Magnus Hagander (magnus@hagander.net) wrote: > It would make the URLs actually short, but as mentioned upthread, that > wouldn't work at all if offline. So it'd be a tradeoff between those, but > so are pretty much all other options that don't include the full message-id. This is a bit of a crazy idea, but in the new list system, couldn't we add a header which includes "our" surrogate message-id? Or possibly the entire URL to the message, and maybe the URL for the entire thread? Thanks! Stephen
On 11/18/16 4:35 PM, Magnus Hagander wrote: > Another option would be to teach the URL shortener about our messages > specifically, and just use an internal surrogate key we already have for > them. That way it could be something like the current Planet URLs (which > can be for example http://postgr.es/p/3Dl), so much shorter. To post one > people would have to go to a webform and paste in the messageid or > existing URL though -- or we could put a link on the page in the archives. > > It would make the URLs actually short, but as mentioned upthread, that > wouldn't work at all if offline. So it'd be a tradeoff between those, > but so are pretty much all other options that don't include the full > message-id. Would it be possible to stick that surrogate key into outgoing list messages as an X- header? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
On 11/18/2016 07:07 PM, Stephen Frost wrote: > Magnus, > > * Magnus Hagander (magnus@hagander.net) wrote: >> It would make the URLs actually short, but as mentioned upthread, that >> wouldn't work at all if offline. So it'd be a tradeoff between those, but >> so are pretty much all other options that don't include the full message-id. > This is a bit of a crazy idea, but in the new list system, couldn't we > add a header which includes "our" surrogate message-id? Or possibly the > entire URL to the message, and maybe the URL for the entire thread? > > I had similar ideas. cheers andrew
On November 18, 2016 1:06:18 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake <jd@commandprompt.com> >wrote: >>> Why not hash the URL? Something like: >>> Http://postgresopen.org/archive/743257890976432 > >> I suggested that upthread... > >Don't like the hashing idea because that would be useless for >searching, >eg, one's own local mail archives. Also, if you are looking at a >message >in your own mail store when composing a commit message (which I >generally >am, don't know about other committers) how are you going to get the >hash? >I think it's important to have the message-ID in cleartext. I do ask of that offline or at least locally. So I won't use something that makes that uncomfortable. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Fri, Nov 18, 2016 at 6:05 PM, Andres Freund <andres@anarazel.de> wrote: > I do ask of that offline or at least locally. So I won't use something that makes that uncomfortable. No committer here. But I do search for mails using the discussion ID present in the log message by querying in my local mail box copy on a more or less daily basis. So having a hash will clearly reduce the flexibility of how things are possible today. -- Michael
On 11/18/2016 09:05 PM, Andres Freund wrote: > > On November 18, 2016 1:06:18 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think it's important to have the message-ID in cleartext. > I do ask of that offline or at least locally. So I won't use something that makes that uncomfortable. > I agree. My original proposal preserved the Message-ID. I don't think the hashing proposal would work well. cheers andrew
On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost <sfrost@snowman.net> wrote:
Magnus,
* Magnus Hagander (magnus@hagander.net) wrote:
> It would make the URLs actually short, but as mentioned upthread, that
> wouldn't work at all if offline. So it'd be a tradeoff between those, but
> so are pretty much all other options that don't include the full message-id.
This is a bit of a crazy idea, but in the new list system, couldn't we
add a header which includes "our" surrogate message-id? Or possibly the
entire URL to the message, and maybe the URL for the entire thread?
I'd rather not tie those systems in that tightly. I think they are much better off being de-coupled.
That said, what we could do is invent our own "id". We could either use a separate surrogate key, or we could do the sha-1 hash of the messageid. And stick that in a header, which could then be searched for both locally and remotely.
Magnus, * Magnus Hagander (magnus@hagander.net) wrote: > On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost <sfrost@snowman.net> wrote: > > * Magnus Hagander (magnus@hagander.net) wrote: > > > It would make the URLs actually short, but as mentioned upthread, that > > > wouldn't work at all if offline. So it'd be a tradeoff between those, but > > > so are pretty much all other options that don't include the full > > message-id. > > > > This is a bit of a crazy idea, but in the new list system, couldn't we > > add a header which includes "our" surrogate message-id? Or possibly the > > entire URL to the message, and maybe the URL for the entire thread? > > I'd rather not tie those systems in that tightly. I think they are much > better off being de-coupled. I get that, but... > That said, what we could do is invent our own "id". We could either use a > separate surrogate key, or we could do the sha-1 hash of the messageid. And > stick that in a header, which could then be searched for both locally and > remotely. Yeah, that's a good thought too. I think we'd need to use a SHA1 to avoid collisions which means that it'll be a bit longer than if we used an actual ID, but it shouldn't be *too* long. Thanks! Stephen
On 11/19/2016 07:36 AM, Stephen Frost wrote: > Magnus, > > * Magnus Hagander (magnus@hagander.net) wrote: >> On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost <sfrost@snowman.net> wrote: >>> * Magnus Hagander (magnus@hagander.net) wrote: >>>> It would make the URLs actually short, but as mentioned upthread, that >>>> wouldn't work at all if offline. So it'd be a tradeoff between those, but >>>> so are pretty much all other options that don't include the full >>> message-id. >>> >>> This is a bit of a crazy idea, but in the new list system, couldn't we >>> add a header which includes "our" surrogate message-id? Or possibly the >>> entire URL to the message, and maybe the URL for the entire thread? >> I'd rather not tie those systems in that tightly. I think they are much >> better off being de-coupled. > I get that, but... > >> That said, what we could do is invent our own "id". We could either use a >> separate surrogate key, or we could do the sha-1 hash of the messageid. And >> stick that in a header, which could then be searched for both locally and >> remotely. > Yeah, that's a good thought too. I think we'd need to use a SHA1 to > avoid collisions which means that it'll be a bit longer than if we used > an actual ID, but it shouldn't be *too* long. > I can think of at least one scenario where you might not easily have access to any invented ID - you're the author and you have mailing list me-too turned off, so you don't have anything that the mailing list has inserted. I honestly think we should just stick with the Message-ID value and get over the ugliness. Putting the clickable URL in a header("X-Archive-Link" ?) is a good idea, though. Using my MUA (Thunderbird) that would make it as simple to get as View Source (Ctrl-U) and a simple C&P, which would make committers' lives easy. I bet others might appreciate it too. cheers andrew
<p dir="ltr"><p dir="ltr">On Nov 19, 2016 15:33, "Andrew Dunstan" <<a href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> ><br /> ><br /> ><br /> > On 11/19/201607:36 AM, Stephen Frost wrote:<br /> >><br /> >> Magnus,<br /> >><br /> >> * Magnus Hagander(<a href="mailto:magnus@hagander.net">magnus@hagander.net</a>) wrote:<br /> >>><br /> >>> On Sat,Nov 19, 2016 at 1:07 AM, Stephen Frost <<a href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>> wrote:<br />>>>><br /> >>>> * Magnus Hagander (<a href="mailto:magnus@hagander.net">magnus@hagander.net</a>)wrote:<br /> >>>>><br /> >>>>> Itwould make the URLs actually short, but as mentioned upthread, that<br /> >>>>> wouldn't work at all ifoffline. So it'd be a tradeoff between those, but<br /> >>>>> so are pretty much all other options thatdon't include the full<br /> >>>><br /> >>>> message-id.<br /> >>>><br /> >>>>This is a bit of a crazy idea, but in the new list system, couldn't we<br /> >>>> add a headerwhich includes "our" surrogate message-id? Or possibly the<br /> >>>> entire URL to the message, and maybethe URL for the entire thread?<br /> >>><br /> >>> I'd rather not tie those systems in that tightly.I think they are much<br /> >>> better off being de-coupled.<br /> >><br /> >> I get that, but...<br/> >><br /> >>> That said, what we could do is invent our own "id". We could either use a<br /> >>>separate surrogate key, or we could do the sha-1 hash of the messageid. And<br /> >>> stick that ina header, which could then be searched for both locally and<br /> >>> remotely.<br /> >><br /> >>Yeah, that's a good thought too. I think we'd need to use a SHA1 to<br /> >> avoid collisions which meansthat it'll be a bit longer than if we used<br /> >> an actual ID, but it shouldn't be *too* long.<br /> >><br/> ><br /> ><br /> > I can think of at least one scenario where you might not easily have access to anyinvented ID - you're the author and you have mailing list me-too turned off, so you don't have anything that the mailinglist has inserted. I honestly think we should just stick with the Message-ID value and get over the ugliness.<br />><br /> > Putting the clickable URL in a header("X-Archive-Link" ?) is a good idea, though. Using my MUA (Thunderbird)that would make it as simple to get as View Source (Ctrl-U) and a simple C&P, which would make committers'lives easy. I bet others might appreciate it too.<br /><p dir="ltr">As a thunderbird user you might be interestedin something like <a href="https://github.com/mhagander/pgarchives">https://github.com/mhagander/pgarchives</a>. I don't know if it works withmodern versions of thunderbird, but hopefully it does. And would be more convenient than the view source way.. <p dir="ltr">/Magnus
* Magnus Hagander (magnus@hagander.net) wrote: > On Nov 19, 2016 15:33, "Andrew Dunstan" <andrew@dunslane.net> wrote: > > I can think of at least one scenario where you might not easily have > access to any invented ID - you're the author and you have mailing list > me-too turned off, so you don't have anything that the mailing list has > inserted. I honestly think we should just stick with the Message-ID value > and get over the ugliness. That's actually not the case if we use a hash, because the client could figure out what the hash is before sending it. > > Putting the clickable URL in a header("X-Archive-Link" ?) is a good idea, > though. Using my MUA (Thunderbird) that would make it as simple to get as > View Source (Ctrl-U) and a simple C&P, which would make committers' lives > easy. I bet others might appreciate it too. > > As a thunderbird user you might be interested in something like > https://github.com/mhagander/pgarchives. I don't know if it works with > modern versions of thunderbird, but hopefully it does. And would be more > convenient than the view source way.. Particulalrly if there is an extension for it... Thanks! Stephen
On 11/19/2016 10:11 AM, Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> On Nov 19, 2016 15:33, "Andrew Dunstan" <andrew@dunslane.net> wrote: >>> I can think of at least one scenario where you might not easily have >> access to any invented ID - you're the author and you have mailing list >> me-too turned off, so you don't have anything that the mailing list has >> inserted. I honestly think we should just stick with the Message-ID value >> and get over the ugliness. > That's actually not the case if we use a hash, because the client could > figure out what the hash is before sending it. The fact that it could possibly be done is not a good reason for doing it. Every proposal along these lines strikes me as making more unobvious hoops for people to jump through. We're just reinventing the wheel here because we don't like the color of the standard wheels that some email MUAs produce. cheers andrew
On 11/17/2016 01:02 PM, Andrew Dunstan wrote: > I love seeing references to email threads in commit messages. It would > make them a lot friendlier though if a full http URL were included > instead of just a Message-ID, i.e. instead of <foo1234@bar.com> put > <https://www.postgresql.org/message-id/foo1234@bar.com>. I know this is > a bit more trouble. but not that much, and it would make it very easy to > follow with just a mouse click. This thread as a whole is going on and on. Instead I thought I would reply back to the OP and see where that goes. I too like to see references in commit messages to the email threads. It definitely makes it easier to track the collaboration of the commit. I wonder if now is the time (again) to consider an issue tracker. Think about it! This whole thread would be solved with a commit message that said: Allow replicated slaves to load balance plans to take load off the master per #18235 -- Robert Haas Then all you have to do is hit #18235 into the issue tracker and viola! I know our community historically has been against most things NIH but if we step back objectively --- using an issue tracker for this is certainly not any more crazy that implementing yet another new wheel. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
Andrew Dunstan <andrew@dunslane.net> writes: > On 11/19/2016 10:11 AM, Stephen Frost wrote: >> That's actually not the case if we use a hash, because the client could >> figure out what the hash is before sending it. > The fact that it could possibly be done is not a good reason for doing > it. Quite. I will *not* go along with any proposal that requires me to duplicate some hashing logic being done elsewhere. Way too much risk of error there. > Every proposal along these lines strikes me as making more unobvious > hoops for people to jump through. We're just reinventing the wheel here > because we don't like the color of the standard wheels that some email > MUAs produce. Yeah, anything like this would be going very very far out of our way to keep these lines in commit messages under an arbitrary limit (which we're already exceeding anyway in many cases). I'm inclined to think we should just straight up decide that having the message link be a clickable URL is worth the longer lines, or that it is not. Personally I vote for "not", but I recognize that I might be in the minority. BTW, before we give up completely on reconciling the two objectives, is anyone aware of a line-continuation convention that would be likely to work? If we could do something like Discussion: https://www.postgresql.org/message-id/\ CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com it would improve matters all around. regards, tom lane
"Joshua D. Drake" <jd@commandprompt.com> writes: > I wonder if now is the time (again) to consider an issue tracker. That would make the problem at hand worse, not better, because you'd get nothing at all for cases that were too trivial to make an issue tracker entry for, or that the committer couldn't be bothered to go find in the issue tracker. We don't even have very widespread adherence to the cite-a-message-thread convention yet (so far as I can tell, Andres and I are the only committers doing it at all). Adding another step of bureaucracy to our processes is just going to fail miserably. regards, tom lane
<div dir="auto">My solution requires that everything have an issue. E.g., hackers becomes a tracker.<div dir="auto"><br /></div><divdir="auto">Sincerely,</div><div dir="auto"> Jd</div></div><div class="gmail_extra"><br /><div class="gmail_quote">OnNov 19, 2016 09:04, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<brtype="attribution" /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"JoshuaD. Drake" <<a href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>> writes:<br/> > I wonder if now is the time (again) to consider an issue tracker.<br /><br /> That would make the problemat hand worse, not better, because you'd<br /> get nothing at all for cases that were too trivial to make an issue<br/> tracker entry for, or that the committer couldn't be bothered to go<br /> find in the issue tracker. We don'teven have very widespread adherence<br /> to the cite-a-message-thread convention yet (so far as I can tell,<br /> Andresand I are the only committers doing it at all). Adding another<br /> step of bureaucracy to our processes is justgoing to fail miserably.<br /><br /> regards, tom lane<br /></blockquote></div></div>
On Sat, Nov 19, 2016 at 5:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/19/2016 10:11 AM, Stephen Frost wrote:
>> That's actually not the case if we use a hash, because the client could
>> figure out what the hash is before sending it.
> The fact that it could possibly be done is not a good reason for doing
> it.
Quite. I will *not* go along with any proposal that requires me to
duplicate some hashing logic being done elsewhere. Way too much risk
of error there.
SHA-1 is fairly well defined, but sure, I can see your issue -- dealing with leading spaces/trailing spaces and whatnot can certainly cause trouble.
> Every proposal along these lines strikes me as making more unobvious
> hoops for people to jump through. We're just reinventing the wheel here
> because we don't like the color of the standard wheels that some email
> MUAs produce.
Yeah, anything like this would be going very very far out of our way to
keep these lines in commit messages under an arbitrary limit (which we're
already exceeding anyway in many cases). I'm inclined to think we should
just straight up decide that having the message link be a clickable URL is
worth the longer lines, or that it is not. Personally I vote for "not",
but I recognize that I might be in the minority.
BTW, before we give up completely on reconciling the two objectives,
is anyone aware of a line-continuation convention that would be likely
to work? If we could do something like
Discussion: https://www.postgresql.org/message-id/\
CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8Zd whHT88LQ@mail.gmail.com
I don't think there is such a thing. There is continuation at the mail header line level, but not for an URL in the contents of the message. And this is in the commit message itself, so nobody really knows what the viewer will be using -- it could be our list archives or a local copy of the commit mail, but it could also be the git log (viewed locally, through our gitweb site, or through github or some other such site).
We can put just the message-id in there and hack our gitweb instance to know how to turn that into links on our site. But that would only cover *our* gitweb, and not all the other potential ways to view it. I'm pretty sure there is no standard that will work across all the different potential views.
We can replace the website part with a http://postgr.es/m/<messageid> which will make it a bit shorter and still as easy to generate from the client side and to search off. It'd be trivial to do, and since there is no state held at the forwarder for it, it wouldn't introduce a risk of "losing the forwards at some point in the future". But the bulk of the URL, being the messageid, would remain.
On 11/20/2016 06:55 AM, Magnus Hagander wrote: > > > We can replace the website part with a http://postgr.es/m/<messageid> > which will make it a bit shorter and still as easy to generate from > the client side and to search off. It'd be trivial to do, and since > there is no state held at the forwarder for it, it wouldn't introduce > a risk of "losing the forwards at some point in the future". But the > bulk of the URL, being the messageid, would remain. > > > That's 19 extra characters, less 2 if you remove the <> delimiters. I think the extra usability makes the slight increase in ugliness worth it. Can we just agree or disagree on this? cheers andrew
On Sun, Nov 20, 2016 at 3:59 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
--
On 11/20/2016 06:55 AM, Magnus Hagander wrote:
We can replace the website part with a http://postgr.es/m/<messageid> which will make it a bit shorter and still as easy to generate from the client side and to search off. It'd be trivial to do, and since there is no state held at the forwarder for it, it wouldn't introduce a risk of "losing the forwards at some point in the future". But the bulk of the URL, being the messageid, would remain.
That's 19 extra characters, less 2 if you remove the <> delimiters. I think the extra usability makes the slight increase in ugliness worth it. Can we just agree or disagree on this?
I personally don't really care either way, just wanted people to know that this option is available. (And it would be without the <> characters, of course). I doubt it's worth the trouble to do it if we're keeping the full msgid.
Andrew Dunstan <andrew@dunslane.net> writes: > On 11/20/2016 06:55 AM, Magnus Hagander wrote: >> We can replace the website part with a http://postgr.es/m/<messageid> >> which will make it a bit shorter and still as easy to generate from >> the client side and to search off. > That's 19 extra characters, less 2 if you remove the <> delimiters. I > think the extra usability makes the slight increase in ugliness worth > it. Can we just agree or disagree on this? I'm prepared to go along with this if there's general agreement. However, maybe we should make it actually work first, because I get a 404 from http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@dunslane.net which ought to be the URL for your message. I tried the same experiment for some of the older messages in this thread, and those are 404 too. BTW, should it be "http:" or "https:"? regards, tom lane
On Sun, Nov 20, 2016 at 5:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/20/2016 06:55 AM, Magnus Hagander wrote:
>> We can replace the website part with a http://postgr.es/m/<messageid>
>> which will make it a bit shorter and still as easy to generate from
>> the client side and to search off.
> That's 19 extra characters, less 2 if you remove the <> delimiters. I
> think the extra usability makes the slight increase in ugliness worth
> it. Can we just agree or disagree on this?
I'm prepared to go along with this if there's general agreement.
However, maybe we should make it actually work first, because I
get a 404 from
http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@ dunslane.net
which ought to be the URL for your message. I tried the same experiment
for some of the older messages in this thread, and those are 404 too.
Right, it hasn't been set up yet. Pending the actual outcome of this thread.
BTW, should it be "http:" or "https:"?
As of today both should work, so it should be https.
On 11/20/2016 03:59 PM, Andrew Dunstan wrote: > > On 11/20/2016 06:55 AM, Magnus Hagander wrote: >> >> We can replace the website part with a http://postgr.es/m/<messageid> >> which will make it a bit shorter and still as easy to generate from >> the client side and to search off. It'd be trivial to do, and since >> there is no state held at the forwarder for it, it wouldn't introduce >> a risk of "losing the forwards at some point in the future". But the >> bulk of the URL, being the messageid, would remain. > > That's 19 extra characters, less 2 if you remove the <> delimiters. I > think the extra usability makes the slight increase in ugliness worth > it. Can we just agree or disagree on this? If non-committers are voting, I'll add my +1 to this. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 11/20/2016 11:34 AM, Magnus Hagander wrote: > > > > I'm prepared to go along with this if there's general agreement. > However, maybe we should make it actually work first, because I > get a 404 from > > http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@dunslane.net > <http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@dunslane.net> > > which ought to be the URL for your message. I tried the same > experiment > for some of the older messages in this thread, and those are 404 too. > > > Right, it hasn't been set up yet. Pending the actual outcome of this > thread. > > I think it's worth having independently of this. cheers andrew
On 11/19/2016 06:38 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Every proposal along these lines strikes me as making more unobvious >> hoops for people to jump through. We're just reinventing the wheel here >> because we don't like the color of the standard wheels that some email >> MUAs produce. > > Yeah, anything like this would be going very very far out of our way to > keep these lines in commit messages under an arbitrary limit (which we're > already exceeding anyway in many cases). I'm inclined to think we should > just straight up decide that having the message link be a clickable URL is > worth the longer lines, or that it is not. Personally I vote for "not", > but I recognize that I might be in the minority. Agreed. I'm happy with the status quo. But if we want to make them clickable, let's just bite the bullet and start doing: Discussion: https://www.postgresql.org/message-id/<message-id> The point of keeping the lines short is to make the text in the commit more pleasant to read, but that hardly applies to a URL. > BTW, before we give up completely on reconciling the two objectives, > is anyone aware of a line-continuation convention that would be likely > to work? If we could do something like > > Discussion: https://www.postgresql.org/message-id/\ > CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com > > it would improve matters all around. That would make it more difficult to parse programmatically, as you couldn't just grep lines beginning with "Discussion: ". Unless we decide to switch to using clickable URLs here, and perhaps even if we do, because we already have a lot of current-format "Discussion: " lines in the git history, it would be nice to change the message archive web interface to know about "Discussion: ". The web interface could view those as clickable links. At the moment, not only are they not clickable, but the interface even obfuscates them, thinking that the message-ids are email addresses, making copy-pasting harder too: Discussion: <26681(dot)1477940227(at)sss(dot)pgh(dot)pa(dot)us> - Heikki
On Sun, Nov 20, 2016 at 11:02 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 11/20/2016 11:34 AM, Magnus Hagander wrote:
I'm prepared to go along with this if there's general agreement.
However, maybe we should make it actually work first, because I
get a 404 from
http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@duns lane.net
<http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@dun slane.net>
which ought to be the URL for your message. I tried the same
experiment
for some of the older messages in this thread, and those are 404 too.
Right, it hasn't been set up yet. Pending the actual outcome of this thread.
I think it's worth having independently of this.
I went to do this on the train this morning and realized it was a little bit more involved than I thought. The reason for that is that I'm planning to restructure a couple of other things on that box (which also hosts planet postgres and has some legacy stuff since a very old version of that one around). Thus it'll take a bit longer, but I will try to get to it as soon as I can. Shouldn't be a problem to have it done this week at least.
On Mon, Nov 21, 2016 at 11:04 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Sun, Nov 20, 2016 at 11:02 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 11/20/2016 11:34 AM, Magnus Hagander wrote:
I'm prepared to go along with this if there's general agreement.
However, maybe we should make it actually work first, because I
get a 404 from
http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@duns lane.net
<http://postgr.es/m/29df5b73-d823-ade4-cb17-47142742a83c@dun slane.net>
which ought to be the URL for your message. I tried the same
experiment
for some of the older messages in this thread, and those are 404 too.
Right, it hasn't been set up yet. Pending the actual outcome of this thread.
I think it's worth having independently of this.I went to do this on the train this morning and realized it was a little bit more involved than I thought. The reason for that is that I'm planning to restructure a couple of other things on that box (which also hosts planet postgres and has some legacy stuff since a very old version of that one around). Thus it'll take a bit longer, but I will try to get to it as soon as I can. Shouldn't be a problem to have it done this week at least.
Magnus Hagander <magnus@hagander.net> writes: > Ok, we now have it. https://postgr.es/m/messageid will redirect to that > messageid in the main archives. I pushed a patch using this new convention: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dafa0848da11260e9510c699e7060171336cb550 While the URL seems to work, I notice that gitweb doesn't show it as a clickable link in the above page. Is that fixable? regards, tom lane
On Mon, Nov 28, 2016 at 3:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- Magnus Hagander <magnus@hagander.net> writes:
> Ok, we now have it. https://postgr.es/m/messageid will redirect to that
> messageid in the main archives.
I pushed a patch using this new convention:
https://git.postgresql.org/gitweb/?p=postgresql.git;a= commitdiff;h= dafa0848da11260e9510c699e70601 71336cb550
While the URL seems to work, I notice that gitweb doesn't show it as
a clickable link in the above page. Is that fixable?
That seems to be because your message-id looks like a git commit hash. It does the same with your messageid's in previous commits, does it not?
I don't really read perl enough to take it apart. But http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code (we're probably on an older version). I'm guessing it's coming out of format_log_line (http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n2035). (the version we have only has the part that looks for the hash).
Doesn't seem to be configurable. We can of course turn that off completely, but in that case it will no longer match any other git hash references in commit messages, so that might be a net loss.
I wonder if it's worth forking gitweb to make it do explicitly what we want for this -- that is recognize all the different kinds of things that would be interesting here. But that fork should probably be done by somebody with some more perl skills than me :)
Magnus Hagander wrote: > I don't really read perl enough to take it apart. But > http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code > (we're probably on an older version). I'm guessing it's coming out of > format_log_line ( > http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n2035). (the > version we have only has the part that looks for the hash). I think if we do want to fork, we should be looking at git_print_log http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n4580 There's a regexp match that looks for "https://" but only when preceded with "link: " (which is a bit odd, isn't it?). > I wonder if it's worth forking gitweb to make it do explicitly what we want > for this -- that is recognize all the different kinds of things that would > be interesting here. But that fork should probably be done by somebody with > some more perl skills than me :) I think changing message-id links to URLs would be veyr handy, but before proposing a fork I would like to have a better idea of how much effort it entails. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/28/2016 09:49 AM, Alvaro Herrera wrote: > Magnus Hagander wrote: > >> I don't really read perl enough to take it apart. But >> http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl is the code >> (we're probably on an older version). I'm guessing it's coming out of >> format_log_line ( >> http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n2035). (the >> version we have only has the part that looks for the hash). > I think if we do want to fork, we should be looking at git_print_log > http://git.kernel.org/cgit/git/git.git/tree/gitweb/gitweb.perl#n4580 > There's a regexp match that looks for "https://" but only when preceded > with "link: " (which is a bit odd, isn't it?). > >> I wonder if it's worth forking gitweb to make it do explicitly what we want >> for this -- that is recognize all the different kinds of things that would >> be interesting here. But that fork should probably be done by somebody with >> some more perl skills than me :) > I think changing message-id links to URLs would be veyr handy, but > before proposing a fork I would like to have a better idea of how much > effort it entails. > I should point out that the link as Tom put it in his commit message is working fine on every MUA that I have tried: Thunderbird (my usual MUA), the GMail web interface, and the native MUAs on my Android Tablet and my iPhone. So I'm pretty happy with that, and want to make sure that nothing we do to accomodate gitweb would interfere with it. From my POV the pattern Tom used in that commit is perfect. If there's a lack of perl-fu to do it, I hope to be in a better position to help a bit with that in a couple of weeks. cheers andrew
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
On 11/30/2016 04:52 PM, Peter Eisentraut wrote: > 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. Agreed. I just did my first commit with the shortened URL, and I didn't like it. If we want to use URLs, let's use the canonical https://www.postgresql.org/message-id/<message-id> format. > 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. Right, we can't control the length of the URL, because it contains the message-id, which can be arbitrarily long. - Heikki
On 11/30/2016 10:46 AM, Heikki Linnakangas wrote: > > Agreed. I just did my first commit with the shortened URL, and I > didn't like it. If we want to use URLs, let's use the canonical > https://www.postgresql.org/message-id/<message-id> format. > >> 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. > > Right, we can't control the length of the URL, because it contains the > message-id, which can be arbitrarily long. Here is a url with one of the long gmail Message-IDs that I arbitrarily picked out of a recent mail thread: https://www.postgresql.org/message-id/CAB7nPqTHyDYF-FO+fZvxRhz-7_hPTm4RodBcsy9-NoqHvEtc3w@mail.gmail.com I'll be interested to know if it breaks anyone's MUA. If it doesn't all we will be arguing about are aesthetics, and I'ma firm believer in function over form. cheers andrew
On 30 November 2016 at 16:19, Andrew Dunstan <andrew@dunslane.net> wrote: > > https://www.postgresql.org/message-id/CAB7nPqTHyDYF-FO+fZvxRhz-7_hPTm4RodBcsy9-NoqHvEtc3w@mail.gmail.com > > I'll be interested to know if it breaks anyone's MUA. If it doesn't all we > will be arguing about are aesthetics, and I'm a firm believer in function > over form. I can't say I feel especially strongly either way on this but just to toss out a small thing that might make a small difference.... If you happen to know how your message-ids are generated then you might be able to do something useful with them. For instance, you could search all git commits for urls to messages you wrote -- for instance any commit that has CAB7nPq is referencing a message written by Michael Paquier. On the other hand you could put something naughty in the message-id forcing everyone else to use URLs with dirty words in them. Or with words like "terrorist" in them. Or with some javascript/html injection attack of some sort... -- greg
On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark <stark@mit.edu> wrote: > On 30 November 2016 at 16:19, Andrew Dunstan <andrew@dunslane.net> wrote: >> >> https://www.postgresql.org/message-id/CAB7nPqTHyDYF-FO+fZvxRhz-7_hPTm4RodBcsy9-NoqHvEtc3w@mail.gmail.com >> >> I'll be interested to know if it breaks anyone's MUA. If it doesn't all we >> will be arguing about are aesthetics, and I'm a firm believer in function >> over form. > > I can't say I feel especially strongly either way on this but just to > toss out a small thing that might make a small difference.... > > If you happen to know how your message-ids are generated then you > might be able to do something useful with them. For instance, you > could search all git commits for urls to messages you wrote -- for > instance any commit that has CAB7nPq is referencing a message written > by Michael Paquier. > > On the other hand you could put something naughty in the message-id > forcing everyone else to use URLs with dirty words in them. Or with > words like "terrorist" in them. Or with some javascript/html injection > attack of some sort... ...or the name of your company/your email hosting provider's company... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark <stark@mit.edu> wrote: >> I can't say I feel especially strongly either way on this but just to >> toss out a small thing that might make a small difference.... >> >> If you happen to know how your message-ids are generated then you >> might be able to do something useful with them. For instance, you >> could search all git commits for urls to messages you wrote -- for >> instance any commit that has CAB7nPq is referencing a message written >> by Michael Paquier. >> >> On the other hand you could put something naughty in the message-id >> forcing everyone else to use URLs with dirty words in them. Or with >> words like "terrorist" in them. Or with some javascript/html injection >> attack of some sort... > ...or the name of your company/your email hosting provider's company... I think this is a straw man. We've already decided to use message-IDs as the basic identity of messages for this purpose; other proposals were considered before and rejected as too inconvenient. When and if somebody tries to game that, we can do something about it, but I'm not very worried. It's not like it's not trivial to get your company's name, or $badword of your choice, into the archives already. The former is more or less standard practice, in fact, as per this very message: > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company regards, tom lane
On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Nov 30, 2016 at 1:50 PM, Greg Stark <stark@mit.edu> wrote: >>> I can't say I feel especially strongly either way on this but just to >>> toss out a small thing that might make a small difference.... >>> >>> If you happen to know how your message-ids are generated then you >>> might be able to do something useful with them. For instance, you >>> could search all git commits for urls to messages you wrote -- for >>> instance any commit that has CAB7nPq is referencing a message written >>> by Michael Paquier. >>> >>> On the other hand you could put something naughty in the message-id >>> forcing everyone else to use URLs with dirty words in them. Or with >>> words like "terrorist" in them. Or with some javascript/html injection >>> attack of some sort... > >> ...or the name of your company/your email hosting provider's company... > > I think this is a straw man. We've already decided to use message-IDs > as the basic identity of messages for this purpose; other proposals > were considered before and rejected as too inconvenient. > > When and if somebody tries to game that, we can do something about it, > but I'm not very worried. It's not like it's not trivial to get your > company's name, or $badword of your choice, into the archives already. > The former is more or less standard practice, in fact, as per this > very message: Sure, of course. But it's a bit different when it's in the commit log. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
All, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > I think this is a straw man. We've already decided to use message-IDs > as the basic identity of messages for this purpose; other proposals > were considered before and rejected as too inconvenient. I tend to agree with Tom on this, for better or worse, message-ID is what we're using. Further, we seem agreed that URLs are what we want to have in the commits rather than just the message-ID. The question on the table at the moment seems to be if we want to use https://postgr.es/m/ or https://postgresql.org/message-id/ as the prefix. Personally, I don't really care and would prefer we just decide something and move on to more interesting technical discussion. I don't really agree with the complaints levied against https://postgr.es/m/, but I'm also not particularly bothered by one long line in each commit message. Thanks! Stephen
Stephen Frost <sfrost@snowman.net> writes: > Further, we seem agreed that URLs are what we want to have in the > commits rather than just the message-ID. If we're set on doing that, then ... > The question on the table at the moment seems to be if we want to use > https://postgr.es/m/ or https://postgresql.org/message-id/ as the > prefix. Personally, I don't really care and would prefer we just decide > something and move on to more interesting technical discussion. I don't > really agree with the complaints levied against https://postgr.es/m/, > but I'm also not particularly bothered by one long line in each commit > message. ... the shortener isn't really doing anything for us. You end up with a line longer than 80 characters with message-IDs generated by either gmail or the bug report form, for instance these examples from recent commits: Discussion: https://postgr.es/m/20161128182113.6527.58926@wrigleys.postgresql.org Discussion: https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com And those two sources comprise the majority of references these days. Even dropping the Discussion: keyword wouldn't get us to lines that don't wrap. So we might as well go with the canonical form, which I take to be https://www.postgresql.org/message-id/<whatever>. Another convention that apparently needs to be discussed is whether or not to point at a whole thread, as in this example from yesterday: Discussion: http://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F5EE995@G01JPEXMBYT05/ I'm kind of -1 on that; it's adding 5 characters for not much. regards, tom lane
On 2016-12-01 18:05:19 -0500, Tom Lane wrote: > ... the shortener isn't really doing anything for us. You end up with a > line longer than 80 characters with message-IDs generated by either gmail > or the bug report form, for instance these examples from recent commits: Still seems quite useful to me. I don't really see much argument against. This: > Discussion: https://postgr.es/m/20161128182113.6527.58926@wrigleys.postgresql.org > Discussion: https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com still looks better than: > Discussion: http://www.postgresql.org/message-id/20161128182113.6527.58926@wrigleys.postgresql.org > Discussion: http://www.postgresql.org/message-id/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com and I see little downside. If we can't keep the first stable, we can't keep the second one stable either. > Another convention that apparently needs to be discussed is whether or > not to point at a whole thread, as in this example from yesterday: > > Discussion: http://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F5EE995@G01JPEXMBYT05/ > > I'm kind of -1 on that; it's adding 5 characters for not much. -1 on that too. Andres
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> When and if somebody tries to game that, we can do something about it, >> but I'm not very worried. It's not like it's not trivial to get your >> company's name, or $badword of your choice, into the archives already. > Sure, of course. But it's a bit different when it's in the commit log. Sure, but there's a filter in that case: if a committer finds a messageID sufficiently offensive, he can just not quote it in the commit message. There's precedent for that; I've more than once omitted crediting somebody's bug report when it was submitted under an obviously fake name. I'm not finding myself fussed about this. regards, tom lane
On 2016-12-01 18:12:34 -0500, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Dec 1, 2016 at 4:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> When and if somebody tries to game that, we can do something about it, > >> but I'm not very worried. It's not like it's not trivial to get your > >> company's name, or $badword of your choice, into the archives already. > > > Sure, of course. But it's a bit different when it's in the commit log. > > Sure, but there's a filter in that case: if a committer finds a messageID > sufficiently offensive, he can just not quote it in the commit message. > There's precedent for that; I've more than once omitted crediting > somebody's bug report when it was submitted under an obviously fake name. > > I'm not finding myself fussed about this. +1. I mean if people behave intentionally offensive, we can always tell them and starting ignoring them. Seems like they'd stop doing that soon, because their patches won't get in/their bugs won't get fixed.
Andres Freund <andres@anarazel.de> writes: > This: >> Discussion: https://postgr.es/m/20161128182113.6527.58926@wrigleys.postgresql.org >> Discussion: https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com > still looks better than: >> Discussion: http://www.postgresql.org/message-id/20161128182113.6527.58926@wrigleys.postgresql.org >> Discussion: http://www.postgresql.org/message-id/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com Really? Somebody expressed the opposite preference upthread, and I agree. "postgr.es" looks, at best, unofficial. regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Andres Freund <andres@anarazel.de> writes: > > This: > > >> Discussion: https://postgr.es/m/20161128182113.6527.58926@wrigleys.postgresql.org > >> Discussion: https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com > > > still looks better than: > > >> Discussion: http://www.postgresql.org/message-id/20161128182113.6527.58926@wrigleys.postgresql.org > >> Discussion: http://www.postgresql.org/message-id/CA+renyUEE29=X01JXdz8_TQvo6n9=2XoEBBRnQ8rkLyr+kjPxQ@mail.gmail.com > > Really? Somebody expressed the opposite preference upthread, and I agree. > "postgr.es" looks, at best, unofficial. I find that to be a particularly compelling point. Also, while it's a pretty minor point, using the canonical form also avoids an unnecessary redirect. Thanks! Stephen