Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes: > Simon Josefsson wrote: >> Timing wise >> maybe it make sense to push out a "snapshot" Git bundle right before you >> branch off stable-202501? The Git bundle would then include master up >> to that point, and the earlier stable-* branches. > > Yes, a day around 2025-01-01 is a reasonable timing for the first > git bundle publication. > >> I suspect it isn't >> likely that stable-202406 will receive that many commits after >> stable-202501 has been branched off? > > 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. > 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. 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? So we need to: 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 -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 /Simon
signature.asc
Description: PGP signature
