Date: Fri, 23 Oct 2020 11:21:49 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	Ian Lawrence Barwick <barwick@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour
Message-ID: <20201023152149.GI16415@tamriel.snowman.net>
References: 
 <CAB8KJ=jYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA@mail.gmail.com>
 <CAB8KJ=h-XALik4M7gv-pX48=+SPWexfaYwa+yTnPwD3DxceXrg@mail.gmail.com>
 <e4934710-73cb-6eef-fd35-6fcfd05f381b@iki.fi>
 <20201023134611.GG16415@tamriel.snowman.net>
 <145522.1603461363@sss.pgh.pa.us>
 <20201023141211.GH16415@tamriel.snowman.net>
 <147812.1603464663@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="wRtZRu2mMGBZ6YQ7"
Content-Disposition: inline
In-Reply-To: <147812.1603464663@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--wRtZRu2mMGBZ6YQ7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > We do need to decide at what point we're going to move forward pg_dump's
> > oldest server version support.
>=20
> I'm not really in a big hurry to move it forward at all.  There were
> good solid reasons to drop support for pre-schema and pre-pg_depend
> servers, because of the messy kluges pg_dump had to implement
> to provide only-partial workarounds for those lacks.  But I don't
> see comparable reasons or code savings that we'll get from dropping
> later versions.
>=20
> There is an argument for dropping support for server versions that
> fail to build anymore with modern toolchains, since once that happens
> it becomes difficult to test, unless you have old executables already
> laying around.  But I don't think we're at that point yet for 8.0 or
> later.  (I rebuilt 7.4 and later when I updated my workstation to
> RHEL8 a few months ago, and they seem fine, though I did use -O0 out of
> fear of -faggressive-loop-optimizations bugs for anything before 8.2.)

Along those same lines though- keeping all of the versions working with
pg_dump requires everyone who is working with pg_dump to have those old
versions not just able to compile but to also take the time to test
against those older versions when making changes.

> But anyway, this was about documentation not code.

Perhaps it didn't come across very well, but I was making an argument
that we should consider them both under a general "every 5 years, go
through and clean out anything that's older than 10 years" type of
policy.  I don't know that we need to spend time doing it every year,
but I wouldn't be against it either.

> What I'm wondering
> about is when to drop things like, say, this bit in the regex docs:
>=20
>     Two significant incompatibilities exist between AREs and the ERE synt=
ax
>     recognized by pre-7.4 releases of <productname>PostgreSQL</productnam=
e>:
>     (etc etc)
>=20
> Seems like we could have gotten rid of that by now, but when exactly
> does it become fair game?  And can we have a non-ad-hoc process for
> getting rid of such cruft?

I agree we should get rid of it and I'm suggesting our policy be that we
only go back about 10 years.  As for the process part, I suggested that
we make it a every-5-year thing, but we could make it be part of the
annual process instead.

We have a number of general tasks that go into each major release and
some of that process is documented, though it seems like a lot isn't as
explicitly spelled out as perhaps it should be.  Here I'm thinking about
things like:

- Get a CFM for each commitfest
- Form an RMT for each major release
- Figure out who will run each major/minor release
- Get translations done
- Review contributors to see who might become a committer
- other things, I'm sure

"Clean up documentation and remove things older than 10 years" could be
another item to get checked off each year.  We might consider looking at
Debian-

https://wiki.debian.org/Teams/ReleaseTeam

and

https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList

Perhaps the past RMTs have thought about this also.  Having these things
written down and available would be good though, and then we should make
sure that they're assigned out and get addressed (maybe that becomes
part of what the RMT does, maybe not).

Thanks,

Stephen

--wRtZRu2mMGBZ6YQ7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJfkvUMAAoJEO1sijiDR2RVs6oP/jDRexa/XRJpkepMQKkT6yw3
7bC4PV8fksyqxeKhUhWkEpMSwBw55L++aBcqR4oXlKYtC5wOyUELagb7dw+ZWhUv
G/VYbcyoVmpjeHzH+vN5x+4EuPVB7YL8KU76y4dwtqvWgyKZeogASChu6egQAevh
A3jWoxRFBiua8ltO+eSivk45YqP0TeS8VxIZiY9UvxBhM/KxYQsz47B5CusLUrko
Ef7e9YRQcM2pjeOh5CZh0jGImbw13ySp49X56UN2sTdL5zaCJbToRy+5LEeNDbe0
C5yT0a0pqmbZiX3xl9dq33kKKn/U7sLNm9aImbOPrH3Ec+cDSZ5ANAMdmgIwY2hQ
zWXL+NeChsiJwWenxNX7CzoXzEetciDcF7CN+8PvNU9ZtBeFoN6mOOVcIsl4H9Qm
bxze4dw1K4i8+QQ3oKkvEacSnDo+TFLtVZpkG7S2CLcX2iYBtNvjl8DrCi6x2k5d
ERVz3t6kOiBEHtgX677kFVkelDmidUyTIGKCXVqs56yvQCuOIuderdKvcmlwTyGm
tMh/gchE7/R29TsQdhPshJPbE/ywgcc7QLhFZzjGFIEV94a1aLtMpmruODvoLsSl
no6nlUfVSp3xJGOFgKHyFK5IYu+1qX8oMQMbjwMp5Z9+32GVa8En5oL1DwuTqmkW
HhuBGAf+4FBBhSbxr1B0
=sBoU
-----END PGP SIGNATURE-----

--wRtZRu2mMGBZ6YQ7--