Re: Fixup a few 2023 copyright years

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fixup a few 2023 copyright years
Date: 2024-04-09 02:36:41
Message-ID: 3607921.1712630201@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Attached is a patch which adjusts the copyright years of 2023 that
> have crept in this year from patches that were written last year and
> committed without adjusting this to 2024.

> The patch isn't produced by src/tools/copyright.pl as that'll
> transform files which are new and only contain "2023" to become
> "2023-2024", which I don't believe is what we want in this case.

Agreed, copyright.pl is not quite the right tool, although you could
use its output as a starting point and manually adjust any wrong
changes.

> Should we do this and is this a good time to?

We *should* do this sometime before branching v17, but I'm not
in any hurry. My thought here is that some of these late changes
might end up getting reverted, in which case touching those files
would add a bit more complexity to the revert. We can do this
sort of mechanical cleanup after the probability of reversion has
declined a bit.

(On the same logic, I'm resisting the temptation to do a tree-wide
pgindent right away. Yeah, the tree is indent-clean according to
the current contents of src/tools/pgindent/typedefs.list, but that
hasn't been maintained with great accuracy, so we'll need an
update and then a pgindent run at some point.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-04-09 02:55:42 Experimental prefetching of buffer memory
Previous Message Tom Lane 2024-04-09 02:27:36 Re: Fixup some StringInfo usages