While I agree the procedure should be somewhere, I'm reluctant to add that to the release procedure. The release procedure is already lengthy, so adding more steps just makes releases harder. There is also no reason to do at the release time and it might be counterproductive if issues arise. Next candidate would be branching procedure (#2963), but the same issues apply there just less severely.

Obviously, a bot update or a scheduled workflow would be nice, but documenting maintenance chores which are done manually is a first step. Maybe we need a document which is sort of a crontab for people where this should go.

I'm open to any alternative solution, this came to mind after locking back on the discussion at last update #2225.

Maybe doc/development/chores.txt?

Maybe doc/development/chores.txt?

Why not markdown file?

I'm not sure what else to add to such a file, but I can create the file and make this PR a draft. From there on we can continue...

Sure, I meant md. There is the autoconf update too or not? I'm sure (afraid) there are other things. Like contributor list.

Sure, I meant md. There is the autoconf update too or not? I'm sure (afraid) there are other things. Like contributor list.

Let us connect @neteler to this issue. Markus, do you have any thoughts on this?

Sure, I meant md. There is the autoconf update too or not?

No, there isn't. Just run autoconf. It used to be documented, here from 8.0 notes (they were removed from later versions of the file):

https://github.com/OSGeo/grass/blob/releasebranch_8_0/doc/howto_release.md#update-of-configure-base-files

What I meant is that it is needed or it is not?

Anyway, let's keep it out of the release howto which has >500 lines on main.

What I meant is that it is needed or it is not?

Yes, the update of config.guess and config.sub files is needed from time to time (at least once a year I'd say).

Just happened to see the config.guess and config.sub files haven't been updated in a year and a half.

BTW: following https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files locally, the autoconf (2.71) step shows several warnings.

If cronjobs are possible this updating could be best done in the CI and generate a PR.

BTW: following https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files locally, the autoconf (2.71) step shows several warnings.

The version number is the key issue there for the warnings.

If cronjobs are possible this updating could be best done in the CI and generate a PR.

That sound like a plan :-)

Here it is:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

BTW: following https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files locally, the autoconf (2.71) step shows several warnings.

The version number is the key issue there for the warnings.

#3199 aims to address those warnings.

What are the commands that should be run in a terminal that you would like to have in CI? I could draft a little GitHub workflow for that, that would run like once a month, and possible to trigger to run as wanted (by starting it in the actions tab). It could make a PR with the changes afterwards.

And any other maintenance tasks could follow the same pattern.

What are the commands that should be run in a terminal that you would like to have in CI?

I believe these steps:
https://github.com/OSGeo/grass/blob/releasebranch_7_8/doc/howto_release.md#update-of-configure-base-files

Then run twice a year or so.

I just finished filing the PR. I wanted at least once a month, so if your workflow log retention is 90 days, we could at least see more than one past run.

Closing this in favour of #3200.