Обсуждение: [MASSMAIL]Fixup a few 2023 copyright years

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.

No other matches aside from .po files from:
git grep -e "Copyright" --and --not -e "2024" --and -e "PostgreSQL
Global Development Group"

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

David

David Rowley <dgrowleyml@gmail.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

On Mon, Apr 08, 2024 at 10:36:41PM -0400, Tom Lane wrote:
> 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.)

The perl code in the tree has gathered dust, on the contrary ;)

I would suggest to also wait until we're clearer with the situation
for all these mechanical changes, which I suspect is going to take 1~2
weeks at least.
--
Michael

On Tue, 9 Apr 2024 at 15:26, Michael Paquier <michael@paquier.xyz> wrote:
> I would suggest to also wait until we're clearer with the situation
> for all these mechanical changes, which I suspect is going to take 1~2
> weeks at least.

Since the Oid resequencing and pgindent run is now done, I've pushed this patch.

David

On Wed, May 15, 2024 at 03:03:00PM +1200, David Rowley wrote:
> On Tue, 9 Apr 2024 at 15:26, Michael Paquier <michael@paquier.xyz> wrote:
>> I would suggest to also wait until we're clearer with the situation
>> for all these mechanical changes, which I suspect is going to take 1~2
>> weeks at least.
>
> Since the Oid resequencing and pgindent run is now done, I've pushed this patch.

Thanks, that looks correct.

While running src/tools/copyright.pl, I have noticed that that a
newline was missing at the end of index_including.sql, as an effect of
the test added by you in a63224be49b8.  I've cleaned up that while on
it, as it was getting added automatically, and we tend to clean these
like in 3f1197191685 or more recently c2df2ed90a82.
--
Michael

On Wed, 15 May 2024 at 17:32, Michael Paquier <michael@paquier.xyz> wrote:
> While running src/tools/copyright.pl, I have noticed that that a
> newline was missing at the end of index_including.sql, as an effect of
> the test added by you in a63224be49b8.  I've cleaned up that while on
> it, as it was getting added automatically, and we tend to clean these
> like in 3f1197191685 or more recently c2df2ed90a82.

Thanks for fixing that.  I'm a little surprised that pgindent does not
fix that sort of thing.

David

David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 15 May 2024 at 17:32, Michael Paquier <michael@paquier.xyz> wrote:
>> While running src/tools/copyright.pl, I have noticed that that a
>> newline was missing at the end of index_including.sql, as an effect of
>> the test added by you in a63224be49b8.  I've cleaned up that while on
>> it, as it was getting added automatically, and we tend to clean these
>> like in 3f1197191685 or more recently c2df2ed90a82.

> Thanks for fixing that.  I'm a little surprised that pgindent does not
> fix that sort of thing.

pgindent does not touch anything but .c and .h files.

I do recommend running "git diff --check" (with --staged if you
already git-added your changes) before you're ready to commit
something.  That does find generic whitespace issues, and I
believe it would've found this one.

            regards, tom lane