Don't retire committers immediately after becoming committers!

[infinisil]

This is a mistake I made in CI.

See #29

[infinisil]

Originally posted by @wolfgangwalther in #29 (comment):

I think there's something else going wrong here, but not sure. IIUC, the api endpoint the automation is looking at should also count commits from when he was not a committer. His last PR was https://github.com/NixOS/nixpkgs/pull/378705/commits, in February this year. That should certainly count.

Only using commit access counts as activity.

---

Originally posted by @wolfgangwalther in #29 (comment):

Maybe there should be a case of closing this PR automatically when the committer makes a commit.
Then this error would be recovered from automatically.

Somebody probably shouldn't be able to automatically maintain commit access by merging a random update PR once a year. Instead it should be up to the commit delegators to evaluate this.

Tbh this "let's ask committers before removing access" idea was never even specified anywhere in RFC 55. The intention of the RFC at least seems to be that access is removed first, and then they're informed of how they can get it back.

[infinisil]

Anyways, I think the best long-term way of fixing this is for the retirement script to check when the person was added to the list in the repository, and not do anything if that's less than a year ago.

This could be done either by:

• Using the commit history of this repo directly, which has the problem that the file only existed less than a year ago, so we can't do this for ~another year
• At least for everybody that's been added in the past year, set their file to contain the date of the addition, then have the retirement script check that date instead of the commit date. Also have the sync script add the date for all additions.

[infinisil]

Workflow enabled again now