Retirement script skipping everybody

[infinisil]

See https://github.com/NixOS/nixpkgs-committers/actions/runs/18044458049/job/51351687770

Fallout from #33, don't quite understand yet why it doesn't work

[MattSturgeon]

Just spot checking a couple entries:

$ git log --reverse --first-parent --format=%cd --date=unix -- members/0x4A6F
1752707308
$ git log --reverse --first-parent --format=%cd --date=unix -- members/zowoq
1752707308
$ git log --reverse --first-parent --format=%cd -- members/zowoq
Thu Jul 17 01:08:28 2025 +0200
$ git log --reverse --first-parent --format=%cd -- members/0x4A6F
Thu Jul 17 01:08:28 2025 +0200
$ cat members/zowoq
$ cat members/0x4A6F

It seems like the explicit dates are missing for some older committers? In fact, only 31 out of 239 have dates:

$ cat members/* | wc -l
31

[infinisil]

That's as expected, see

nixpkgs-committers/scripts/retire.sh

Lines 45 to 62 in 9af5c53

	# We need to know when people received their commit bit to avoid retiring them within the first year.
	# For now this is done either with the git creation date of the file, or its contents:
	#
	# | commit bit reception date | file creation date | file contents |
	# | -------------------------- | ------------------ | -------------- |
	# | A) -∞ - 2024-10-06 | 2025-07-08 | empty |
	# | B) 2024-10-07 - 2025-04-22 | 2025-07-08 | reception date |
	# | C) 2025-08-13 - ∞ | reception date | empty |
	#
	# After 2026-04-23 (one year after C started), the file creation date
	# for all first-year committers will match the reception date,
	# while everybody else will have been a committer for more than one year.
	# This means the code can then be simplified to just
	# check if the file creation date is in the last year.
	#
	# For now however, the code needs to check if the file creation date
	# is before 2025-07-09 to distinguish between periods A and C,
	# so we hardcode that date for the code to use.

[MattSturgeon]

Are the examples I spot-checked not under category B? EDIT: ah, I see they're probably cat A...

commit bit reception date	file creation date	file contents
A) -∞ - 2024-10-06	2025-07-08	empty
B) 2024-10-07 - 2025-04-22	2025-07-08	reception date
C) 2025-08-13 - ∞	reception date	empty

They don't match the table exactly (created 2025-07-17 instead of 2025-07-08), but they do pre-date category C of "on or after 2025-08-13".

So the fact they don't have content seems wrong.

EDIT2:

Hm. I think I understand the intend behaviour better now: an empty file created before the createdOnReception epoch is assumed to have been created at the UNIX epoch, while an empty file created after the createdOnReception epoch uses the git log date.