Обсуждение: Re: 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

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

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

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

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