pgsql: Remove references to Majordomo

On Thu, Jan 17, 2019 at 01:04:44PM +0000, Magnus Hagander wrote:

Remove references to Majordomo

Lists are not handled by Majordomo anymore and haven't been for a while,
so remove the reference and instead direct people to the list server.

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?
--
Michael

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz> wrote:

On Thu, Jan 17, 2019 at 01:04:44PM +0000, Magnus Hagander wrote:

Remove references to Majordomo

Lists are not handled by Majordomo anymore and haven't been for a while,
so remove the reference and instead direct people to the list server.

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for translators?

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz> wrote:

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

regards, tom lane

On Fri, Jan 18, 2019 at 10:02:47AM -0500, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

Yes, I think that it is better to not bother about back-branches and
just do that on HEAD.
--
Michael

On Fri, Jan 18, 2019 at 4:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz>

wrote:

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for

translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

Pushed.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:

On Fri, Jan 18, 2019 at 4:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz>

wrote:

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for

translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

Pushed.

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

I can understand the concern around translators and back-patching and
such, but I don't think we should be waiting another 5 years before we
retire those aliases as having them is preventing us from moving forward
with other infrastructure improvements to our email systems. I also
don't think it'd be ideal to wait until we are ready to retire those
aliases to make the change in the back-branches, so, I really think we
should back-patch this.

I could see an argument for waiting until the next round of releases is
out to give more time to translators, if we think that's necessary, but
given that it's a pretty straight-forward change, I wouldn't think it'd
be too bad..

Thanks!

Stephen

On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost <sfrost@snowman.net> wrote:

Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:

On Fri, Jan 18, 2019 at 4:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz

wrote:

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I

can't

quite make up my mind on if it's a good idea to backpatch that

though --

it's certainly safe enough to do, but it might cause issues for

translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

Pushed.

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

Specifically for pgsql-bugs, yes :) We can special-case that one when the
time comes, and retire the other ones properly.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Magnus Hagander <magnus@hagander.net> writes:

On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost <sfrost@snowman.net> wrote:

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

Specifically for pgsql-bugs, yes :) We can special-case that one when the
time comes, and retire the other ones properly.

If you're hoping to wait till nobody's copy of Postgres mentions the
@postgresql.org addresses, you're going to be waiting a long time.
I don't see a reason to suppose that pre-9.4 copies are going to
disappear from circulation anytime soon. Heck, they haven't even
disappeared from our website, e.g.

https://www.postgresql.org/docs/9.3/bug-reporting.html

So I doubt that back-patching this particular commit would move the
goalposts very much in terms of when we think we can desupport the
@postgresql.org addresses.

regards, tom lane

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost <sfrost@snowman.net> wrote:

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

Specifically for pgsql-bugs, yes :) We can special-case that one when the
time comes, and retire the other ones properly.

That might possibly work.

If you're hoping to wait till nobody's copy of Postgres mentions the
@postgresql.org addresses, you're going to be waiting a long time.

I was thinking that we would want to make sure that supported versions
have the correct address, but if we're fine with special-casing the old
aliases and keeping them working, as Magnus suggests, then I suppose it
doesn't matter.

Thanks!

Stephen

On Sat, Jan 19, 2019 at 01:19:46PM -0500, Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

On Fri, Jan 18, 2019 at 4:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier <michael@paquier.xyz>

wrote:

Wouldn't it be better to also switch the references to pgsql-bugs in
all the C code for the different --help outputs?

You are right, we definitely should. I'll go ahead and fix that. I can't
quite make up my mind on if it's a good idea to backpatch that though --
it's certainly safe enough to do, but it might cause issues for

translators?

Yeah, weak -1 for back-patching. We don't usually like to thrash
translatable messages in the back branches.

Pushed.

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

I can understand the concern around translators and back-patching and
such, but I don't think we should be waiting another 5 years before we
retire those aliases as having them is preventing us from moving forward
with other infrastructure improvements to our email systems.

What are those blocked infrastructure improvements?

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

I can understand the concern around translators and back-patching and
such, but I don't think we should be waiting another 5 years before we
retire those aliases as having them is preventing us from moving forward
with other infrastructure improvements to our email systems.

What are those blocked infrastructure improvements?

+1 for that question. I find myself wondering what infrastructure
improvements could possibly be important enough to justify rushing
this change (or for that matter, ever making it at all).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

Does this also implicitly mean we've just agreed to push back the
retirement of the @postgresql.org aliases for the lists until v11 is
EOL..?

I can understand the concern around translators and back-patching and
such, but I don't think we should be waiting another 5 years before we
retire those aliases as having them is preventing us from moving forward
with other infrastructure improvements to our email systems.

What are those blocked infrastructure improvements?

+1 for that question. I find myself wondering what infrastructure
improvements could possibly be important enough to justify rushing
this change (or for that matter, ever making it at all).

The specific improvements we're talking about are DKIM/DMARC/SPF, which
is becoming more and more important to making sure that the email from
our lists can actually get through to the subscribers.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

What are those blocked infrastructure improvements?

The specific improvements we're talking about are DKIM/DMARC/SPF, which
is becoming more and more important to making sure that the email from
our lists can actually get through to the subscribers.

Certainly those are pretty critical. But can you give us a quick
refresher on why dropping the @postgresql.org list aliases is
necessary for that? I thought we'd already managed to make the
lists compliant with those specs.

regards, tom lane

On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Stephen Frost <sfrost@snowman.net> writes:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

What are those blocked infrastructure improvements?

The specific improvements we're talking about are DKIM/DMARC/SPF, which
is becoming more and more important to making sure that the email from
our lists can actually get through to the subscribers.

Certainly those are pretty critical. But can you give us a quick
refresher on why dropping the @postgresql.org list aliases is
necessary for that? I thought we'd already managed to make the
lists compliant with those specs.

I believe it doesn't, as Stephen also agreed with upthread.

We needed to move our *sending* out of the postgresql.org domain in order
to be able to treat them differently. But there is nothing preventing us

Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:

On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Stephen Frost <sfrost@snowman.net> writes:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

What are those blocked infrastructure improvements?

The specific improvements we're talking about are DKIM/DMARC/SPF, which
is becoming more and more important to making sure that the email from
our lists can actually get through to the subscribers.

Certainly those are pretty critical. But can you give us a quick
refresher on why dropping the @postgresql.org list aliases is
necessary for that? I thought we'd already managed to make the
lists compliant with those specs.

I believe it doesn't, as Stephen also agreed with upthread.

We needed to move our *sending* out of the postgresql.org domain in order
to be able to treat them differently. But there is nothing preventing us
from receiving to e.g. pgsql-bugs@postgresql.org and internally forward it
to @lists.postgresql.org, where we then deliver from.

Yes, I *think* this will work, as long as we are sending it back out
from pgsql-bugs@lists.postgresql.org then we should be able to have SPF
records for lists.postgresql.org and downstream mail servers should be
happy with that, though I still want to actually test it out in our test
instance of PGLister.

This is the main thing- we want to have lists.postgresql.org (and
friends) have SPF (and maybe DKIM..) records which basically say that
malur is allowed to send mail out from those lists (or with those lists
in the From: of the email in the case of DKIM), but we don't want to
make everyone who is sending email from a @postgresql.org have to relay
through our mail servers (well, at least not today.. we may get to a
point in the spam wars where we *have* to do that or their email ends up
not going through, but we aren't quite there yet).

I believe we *can* do the same for all lists, but that part is more a
matter of cleaning up our infrastructure, which has a fair amount of cruft
to deal with those things. We have an easy workaround for a couple of lists
which owuld take only a fairly small amount of traffic over it, but we'd
like to get rid of the cruft to deal with the large batch of them.

Yes, there's this aspect of it also.

Thanks!

Stephen

On Mon, Jan 28, 2019 at 07:29:39PM +0100, Magnus Hagander wrote:

On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Stephen Frost <sfrost@snowman.net> writes:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com> wrote:

What are those blocked infrastructure improvements?

The specific improvements we're talking about are DKIM/DMARC/SPF, which
is becoming more and more important to making sure that the email from
our lists can actually get through to the subscribers.

Certainly those are pretty critical. But can you give us a quick
refresher on why dropping the @postgresql.org list aliases is
necessary for that? I thought we'd already managed to make the
lists compliant with those specs.

I believe it doesn't, as Stephen also agreed with upthread.

We needed to move our *sending* out of the postgresql.org domain in order
to be able to treat them differently. But there is nothing preventing us
from receiving to e.g. pgsql-bugs@postgresql.org and internally forward it
to @lists.postgresql.org, where we then deliver from.

I believe we *can* do the same for all lists, but that part is more a
matter of cleaning up our infrastructure, which has a fair amount of cruft
to deal with those things. We have an easy workaround for a couple of lists
which owuld take only a fairly small amount of traffic over it, but we'd
like to get rid of the cruft to deal with the large batch of them.

Ceasing to accept mail at pgsql-FOO@postgresql.org would cause a concrete,
user-facing loss in that users replying to old messages would get a bounce.
Also, I find pgsql-FOO@lists.postgresql.org uglier, since "lists" adds
negligible information. (The same is true of "pgsql", alas.) If the cost of
keeping pgsql-FOO@postgresql.org is limited to "cruft", I'd prefer to keep
pgsql-FOO@postgresql.org indefinitely.

nm

On Sat, Feb 2, 2019 at 9:18 AM Noah Misch <noah@leadboat.com> wrote:

On Mon, Jan 28, 2019 at 07:29:39PM +0100, Magnus Hagander wrote:

On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Stephen Frost <sfrost@snowman.net> writes:

On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah@leadboat.com>

wrote:

What are those blocked infrastructure improvements?

The specific improvements we're talking about are DKIM/DMARC/SPF,

which

is becoming more and more important to making sure that the email

from

our lists can actually get through to the subscribers.

Certainly those are pretty critical. But can you give us a quick
refresher on why dropping the @postgresql.org list aliases is
necessary for that? I thought we'd already managed to make the
lists compliant with those specs.

I believe it doesn't, as Stephen also agreed with upthread.

We needed to move our *sending* out of the postgresql.org domain in

order

to be able to treat them differently. But there is nothing preventing us
from receiving to e.g. pgsql-bugs@postgresql.org and internally forward

it

to @lists.postgresql.org, where we then deliver from.

I believe we *can* do the same for all lists, but that part is more a
matter of cleaning up our infrastructure, which has a fair amount of

cruft

to deal with those things. We have an easy workaround for a couple of

lists

which owuld take only a fairly small amount of traffic over it, but we'd
like to get rid of the cruft to deal with the large batch of them.

Ceasing to accept mail at pgsql-FOO@postgresql.org would cause a concrete,
user-facing loss in that users replying to old messages would get a bounce.
Also, I find pgsql-FOO@lists.postgresql.org uglier, since "lists" adds
negligible information. (The same is true of "pgsql", alas.) If the cost
of
keeping pgsql-FOO@postgresql.org is limited to "cruft", I'd prefer to keep
pgsql-FOO@postgresql.org indefinitely.

It very specifically *does* convey important information. It may not do so
to you, but posting to an @lists.<something> domain is something that
implies that you understand you are posting to a list, more or less. Thus
it makes a big difference when it comes to things like GDPR, per the
information we have received from people who know a lot more about that
than we do. That part only applies to lists that are being delivered and
archived publicly.

I had forgotten about that part and went back to my notes.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;