Hi Simon, > > stable-202407 is meant to be maintained until 2025-06-30. For one year. > > > > The bundle would then include a branch whose maintenance just ended > > (stable-202401) and one whose maintenance is ongoing. > > I think we need to include all branches forever in the Git bundle, since > projects pin to gnulib git commits and the bundle need to contain all > possible git commits ever used by projects that use gnulib. Otherwise > the bundle may be useless for rebuilding some old release. I initially > thought this would be insanely large, but git compression is really good > and currently the gnulib git bundle is only 80MB and even if that > doubles in 10 years it is still manageable.
Agreed. A rough size estimation: A stable branch contains about 25% or 30% of the commits that happens on the master branch, over one year. With 2 stable branches in parallel, it means that the stable branches together might increase the bundle's size by 50% or 60% — which is a fixed, bounded factor. > > One thing is important, though: That these bundles get accompanied by > > a README that clearly tells that the 2025-01-01 bundle is valid > > only for releases that were made in 2024 and earlier. If, say, a > > coreutils release is made in February 2025, there 2025-01-01 bundle > > will be of no use for that coreutils release, and anyone who wants > > to have a git bundle for that coreutils release will have to wait > > until 2026-01-01. We need to make this clear, because if there was > > a pressure on coreutils (or gettext) to only use gnulib from > > the past year, that would be a major problem for Gnulib development. > > Right. The purpose of this is to have a stable trustworthy archival > trail, not for people to use it as a distribution point instead of a > Savannah git clone. It will be useful for ancient releases, which is > the goal, but for a really new releases nobody can use it. Good that we have agreement here. > README's on ftp.gnu.org are fairly difficult to maintain, how about if > it just contain a URL to a gnulib manual section that we can update > continously? You're right. While technically a README on ftp.gnu.org can be updated via gnupload's --delete option (I believe), it quickly gets forgotten and then becomes out-of-date. Regarding the location of that manual section, I suggest you make it a new section in chapter 21 "Release Management Files". (It would be misplaced in chapter 1, 2, or 3, in my opinion.) > 1) Add a section to the gnulib manual describing what gnulib publish at > ftp.gnu.org and that it is a Git bundle for archival purposes. > > 2) Upload a README to ftp.gnu.org/gnu/gnulib/ with a URL to that gnulib > manual section. > > 3) Prepare and upload the PGP-signed Git bundle. There probably need to > be a small shell script to do this. You wouldn't want to run this in > your development gnulib git repository; I think git bundle may contain > old forgotten 'git commit -a --amend' objects. I suggest something like > this: > > cd $(mktemp -d) > B=stable-202501 > git clone https://git.savannah.gnu.org/git/gnulib.git > # XXX make a reasonable to effort to not use a backdoored checkout if > Savannah happened to be compromised > git -C gnulib fsck > git -C gnulib checkout -B master > git -C gnulib checkout $B > # XXX checkout the other stable branches too, how to automate? git branch -r | grep 'origin/stable-' > git -C gnulib remote remove origin > git -C gnulib gc --prune=now > git -C gnulib -c 'pack.threads=1' bundle create gnulib-20250101.bundle --all > gpg --detach-sign --armor gnulib-20250101.bundle > gpg --verify gnulib-20250101.bundle.asc Sure. Go ahead. Bruno
