question regarding policy for patches to out-of-support branches

Joe Conway <mail@joeconway.com> writes:

I was having a discussion regarding out-of-support branches and effort
to keep them building, but could not for the life of me find any actual
documented policy (although I distinctly remember that we do something...).
Is the policy written down somewhere, or is it only project lore? In
either case, what is the actual policy?

I believe our policy was set in this thread:

/messages/by-id/2923349.1634942313@sss.pgh.pa.us

and you're right that it hasn't really been memorialized anywhere
else. I'm not sure where would be appropriate. Anyway, what
I think the policy is:

* Out-of-support versions back to (currently) 9.2 are still to be
kept buildable on modern toolchains.

* Build failures, regression failures, and easily-fixable compiler
warnings are candidates for fixes.

* We aren't too excited about code that requires external dependencies
(e.g. libpython) though, because those can be moving targets.

* Under no circumstances back-patch anything that changes external
behavior, as the point of the exercise is to be able to test against
the actual behavior of the last releases of these branches.

regards, tom lane

On Wed, Jun 5, 2024 at 8:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joe Conway <mail@joeconway.com> writes:

I was having a discussion regarding out-of-support branches and effort
to keep them building, but could not for the life of me find any actual
documented policy (although I distinctly remember that we do something...).
Is the policy written down somewhere, or is it only project lore? In
either case, what is the actual policy?

I believe our policy was set in this thread:

/messages/by-id/2923349.1634942313@sss.pgh.pa.us

and you're right that it hasn't really been memorialized anywhere
else. I'm not sure where would be appropriate.

Not absolutely sure, but would at least adding a page to PostgreSQL
Wiki about this make sense ?

---
Hannu

On Thu, Jun 6, 2024 at 4:25 AM Hannu Krosing <hannuk@google.com> wrote:

Not absolutely sure, but would at least adding a page to PostgreSQL
Wiki about this make sense ?

I feel like we need to do something. Tom says this is a policy, and
he's made that comment before about other things, but the fact that
they're not memorialized anywhere is a huge problem, IMHO. People
don't read or remember every mailing list discussion forever, and even
if they did, how would we enumerate all the policies for the benefit
of a newcomer? Maybe this belongs in the documentation, maybe in the
wiki, maybe someplace else, but the real issue for me is that policies
have to be discoverable by the people who need to adhere to them, and
old mailing list discussions aren't.

--
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Jun 6, 2024 at 4:25 AM Hannu Krosing <hannuk@google.com> wrote:

Not absolutely sure, but would at least adding a page to PostgreSQL
Wiki about this make sense ?

I feel like we need to do something. Tom says this is a policy, and
he's made that comment before about other things, but the fact that
they're not memorialized anywhere is a huge problem, IMHO.

I didn't say it wasn't ;-)

ISTM we have two basic choices: wiki page, or new SGML docs section.
In the short term I'd lean to a wiki page. It'd be reasonable for

https://wiki.postgresql.org/wiki/Committing_checklist

to link to it (and maybe the existing section there about release
freezes would be more apropos on a "Project policies" page? Not
sure.)

To get a sense of how much of a problem we have, I grepped the git
history for comments mentioning project policies. Ignoring ones
that are really talking about very localized issues, what I found
is attached. It seems like it's little enough that a single wiki
page with subsections ought to be enough. I'm not super handy with
editing the wiki, plus I'm only firing on one cylinder today (seem
to have acquired a head cold at pgconf), so maybe somebody else
would like to draft something?

regards, tom lane

On 6/6/24 14:12, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Jun 6, 2024 at 4:25 AM Hannu Krosing <hannuk@google.com> wrote:

Not absolutely sure, but would at least adding a page to PostgreSQL
Wiki about this make sense ?

I feel like we need to do something. Tom says this is a policy, and
he's made that comment before about other things, but the fact that
they're not memorialized anywhere is a huge problem, IMHO.

I didn't say it wasn't ;-)

ISTM we have two basic choices: wiki page, or new SGML docs section.
In the short term I'd lean to a wiki page. It'd be reasonable for

https://wiki.postgresql.org/wiki/Committing_checklist

to link to it (and maybe the existing section there about release
freezes would be more apropos on a "Project policies" page? Not
sure.)

To get a sense of how much of a problem we have, I grepped the git
history for comments mentioning project policies. Ignoring ones
that are really talking about very localized issues, what I found
is attached. It seems like it's little enough that a single wiki
page with subsections ought to be enough. I'm not super handy with
editing the wiki, plus I'm only firing on one cylinder today (seem
to have acquired a head cold at pgconf), so maybe somebody else
would like to draft something?

I added them here with minimal copy editing an no attempt to organize or
sort into groups:

https://wiki.postgresql.org/wiki/Committing_checklist#Policies

If someone has thoughts on how to improve I am happy to make more changes.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Joe Conway <mail@joeconway.com> writes:

On 6/6/24 14:12, Tom Lane wrote:

To get a sense of how much of a problem we have, I grepped the git
history for comments mentioning project policies. Ignoring ones
that are really talking about very localized issues, what I found
is attached. It seems like it's little enough that a single wiki
page with subsections ought to be enough. I'm not super handy with
editing the wiki, plus I'm only firing on one cylinder today (seem
to have acquired a head cold at pgconf), so maybe somebody else
would like to draft something?

I added them here with minimal copy editing an no attempt to organize or
sort into groups:
https://wiki.postgresql.org/wiki/Committing_checklist#Policies
If someone has thoughts on how to improve I am happy to make more changes.

Thanks! I summoned the energy to make a few more improvements,
particularly updating stuff that seemed out-of-date. I'm sure
there's more that could be added here.

regards, tom lane

On Thu, Jun 6, 2024 at 10:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

I added them here with minimal copy editing an no attempt to organize or
sort into groups:
https://wiki.postgresql.org/wiki/Committing_checklist#Policies
If someone has thoughts on how to improve I am happy to make more changes.

Thanks! I summoned the energy to make a few more improvements,
particularly updating stuff that seemed out-of-date. I'm sure
there's more that could be added here.

This is nice! I wonder if we could interest anyone in creating tooling
that could be used to check some of this stuff -- ideally run as part
of the regular build process, so that you fail to notice that you did
it wrong.

Not all of these rules are subject to automatic verification e.g. it's
hard to enforce that a change to an out-of-support branch makes no
functional change. But an awful lot of them could be, and I would
personally be significantly happier and less stressed if I knew that
'ninja && meson test' was going to tell me that I did it wrong before
I pushed, instead of finding out afterward and then having to drop
everything to go clean it up.

--
Robert Haas
EDB: http://www.enterprisedb.com