triple stability, request for release tags

[Adam Joseph]

Quoting Zack Weinberg (2023-08-18 04:42:32)
> On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote:
> > ... such blunders should be ignored, or at least normalized...
>
> Even more important than this is the principle that config.sub canonical names
> are *never* changed, even if they are wrong according to some external
> standard.

The stability of the set of accepted triples is precious to me as well.

However the patch in question [1] was applied [2] less than seven days after it
was submitted.  It is a bit unfair to quash Po Lu's concerns simply because he
happened to be on vacation that particular week.

Perhaps it is time for GNU config to tag releases?

This could be done near-automatically: every three months a release-YYYY-MM-DD
tag is added to the then-six-months-old HEAD, provided that no objections have
been raised.  This would allow the current prompt application timetable (which
prevents merge conflicts) to continue.

Note that most large distributions upgrade the `config.sub` vendored by their
upstream packages:

  GNU Guix: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/check.scm#n561
  Void:     
https://github.com/void-linux/void-packages/blob/master/common/hooks/pre-configure/01-override-config.sh
  nixpkgs:  
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/update-autotools-gnu-config-scripts.sh

Guidance as to which GNU config commit to use would be appreciated.  "Just use
the latest commit" puts stability in conflict with merge conflict management.
"Use the latest release-YYYY-MM-DD tag" would avoid this conflict.

  - a

[1] https://lists.gnu.org/archive/html/config-patches/2023-06/msg00005.html
[2] https://lists.gnu.org/archive/html/config-patches/2023-07/msg00000.html