Paul Eggert wrote:
> Thanks for handling this. But I'm not quite following. Is this sort of 
> thing recommended for all developers that develop or use Gnulib? If so, 
> should it be documented in the Gnulib manual?

The savannah volunteers are fighting hard to keep savannah working;
similar work is done by the FSF sysadmins regarding lists.gnu.org and
www.gnu.org. The only recent public communications that I know of are
[1][2][3]. Most of what I know is from the IRC channel #savannah,
and the situation can change from one month to the next month.
[4] is not currently up-to-date.

Having said that, what I understood is that it is desirable to
  1) minimize the load on savannah.gnu.org,
  2) use read-only mirrors (that have a delay of a few minutes) instead
     of the master host where possible.

While all of the following is valid for any GNU package hosted on savannah,
Gnulib is affected in particular because it is large (90 MB of compressed
.git folder).

When you develop a GNU package hosted on savannah, of course your main
checkout needs to be with authentication, as shown e.g. in [5].

But other than that, you are accessing savannah in a number of ways:

  * Browsing the git repositories through the web.
    Specialized read-only mirrors exist:
      - https://gitweb.git.savannah.gnu.org/gitweb/
        which replaces https://git.savannah.gnu.org/gitweb/
      - https://cgit.git.savannah.gnu.org/cgit/
        which replaces https://git.savannah.gnu.org/cgit/
    Note that occasionally the read-only mirrors can be overloaded
    (due to the scrapbots); therefore in such situations it may
    be more effective to fetch a repository through 'git clone'
    and then look at the history via 'gitk'.

  * Bootstrapping GNU packages with submodules or subcheckouts.
    (A "subcheckout" is a concept introduced by gitsub.sh;
    it behaves like a submodule without pointing to a fixed commit.)
    If you have a checkout of Gnulib already on your disk, use of
      ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
    completely removes the need to fetch gnulib over the network,
    whereas
      git config --global url.git://git.savannah.gnu.org/.insteadof 
git://git.git.savannah.gnu.org/
      git config --global url.https://git.savannah.gnu.org/git/.insteadof 
https://https.git.savannah.gnu.org/git/
      git config --global url.git://git.savannah.gnu.org/gnulib.git.insteadof 
https://github.com/coreutils/gnulib.git
      git config --global 
url.https://git.savannah.gnu.org/git/gnulib.git.insteadof 
https://github.com/coreutils/gnulib.git
    installs rewrite rules for "git clone" issued
      - by git submodules,
      - by gitsub.sh subcheckouts.

    git.git.savannah.gnu.org and https.git.savannah.gnu.org are read-only
    mirrors for 'git clone', as well as https://github.com/coreutils/gnulib.git
    (for Gnulib only). Their use can make a big difference. I measured
    the following speeds today:

      $ git clone git://git.savannah.gnu.org/gperf.git
      42 KB/sec

      $ git clone git://git.git.savannah.gnu.org/gperf.git
      3.1 MB/sec

      $ git clone https://https.git.savannah.gnu.org/git/gperf.git
      4.5 MB/sec

      $ git clone https://github.com/coreutils/gnulib.git
      25 MB/sec

  * When you have continuous integrations (on GitLab or GitHub for example),
    there are three ways to improve the network use:

      - Use of the read-only mirrors mentioned above.

      - Use of the '--one-time' option that some autopull.sh scripts support.
        It optimizes the network access, assuming that the current directory
        will be used to build the current version only and will be thrown
        away afterwards.

      - GitLab supports caching the entire current directory from one CI run
        to the next. This is quite efficient. The downside is that occasionally
        there's some file left that breaks the build, and you see a strange
        build failure that goes away when you press the "Clear cache" button
        in the GitLab UI.

Where should these things be documented? I don't think the Gnulib manual
is the appropriate place for it. Rather [4] sounds like the better place.

Bruno

[1] https://lists.gnu.org/archive/html/savannah-users/2025-05/msg00002.html
[2] https://savannah.gnu.org/news/?id=10777
[3] https://www.fsf.org/blogs/sysadmin/our-small-team-vs-millions-of-bots
[4] https://savannah.gnu.org/maintenance/UsingGit/
[5] https://savannah.gnu.org/git/?group=gnulib




Reply via email to