On 9/10/22 20:36, Bruno Haible wrote:
Bernhard Voelker wrote:
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.
Bernhard Voelker wrote:
> 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 g
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 branch
[Re-adding bug-gnulib in CC.]
Bruce Korb wrote:
> How about a plain "stable" branch that resolves to whatever the current
> (or previous-to-current) stable branch is? That way my toy builder can
> reference "stable" and I won't worry over updates to what the current
> stable is. :) Thanks.
The
Over the last two years or so, I've noticed that we quite frequently have
commits in Gnulib that fix regressions.
That is, while the documentation says
"The goal is to have a 100% firm interface so that maintainers
can feel free to update to the code in git at any time and know
that their
