On 9/10/22 15:51, Bruno Haible wrote:
Maintaining a stable branch is a small amount of work every month. It does not even need to happen on a regular schedule. Even a schedule of 3 months is OK.
I don't have a strong opinion about it. Here are just my loose thoughts about it. a) Topic branches I personally don't think this is a good idea for gnulib, because most likely nobody but the author will use the topic branch until it gets merged into master (or a stable branch). b) Stable branches. Can help, but see the following from the gnulib users' point of view (upstream and downstream). Other use cases: 1. New upstream / GNU package release. Usually, GNU maintainers pull in the latest changes from gnulib before making a new release. Well, at that time, a lot of platform tests are done, and most problems are found instantly, I'd say. If not, well, then the issue gets fixed in gnulib and a re-release is done with a newer version. 2. Downstream builds. 2a) New downstream build for a new upstream release. When a new upstream version of a package doesn't work, then either the downstream maintainer can pick the fix from gnulib as a patch, or the upstream maintainer will do another release (see above), or at least have gnulib updated to the fix in the package repo. 2b) Aging release failing to build on newer build environment. Well, usually, the downstream maintainer will simply pick the fix from gnulib (or the thereby updated upstream) to make the package work again. As said above, I don't have a strong preference, but as (low-frequent, sigh) gnulib contributor, GNU package maintainer using gnulib, and distro downstream maintainer I didn't have a problem with gnulib stability so far over the past years. Thanks & have a nice day, Berny
