Hi! Simon Josefsson <[email protected]> writes:
> Now https://gitlab.com/gnutls/guile is a read-only archived project. > > I'll try to push out a new release to put a flag down that guile-gnutls > is now on codeberg and that we are open for business there. Nice! > I've setup a read-only GitLab CI/CD project: > > https://gitlab.com/gsasl/guile-gnutls/-/pipelines > > For as long as we have the .gitlab-ci.yml file in the guile-gnutls > project, people can push the codenerh repository to their personal > gitlab space and CI/CD will just work there. Cool, taking advantage of GitLab Corp’s resources. :-) >> I would just use Git tags these days, but then that rules out >> complicated pre-processing à la Gnulib. > > The migration migrated the release page too. But I'm not sure there is > any value in these? We still push tarballs to ftp.gnu.org. Interestingly, the release pages were migrated, but not the files they refer to. See for instance <https://codeberg.org/guile-gnutls/guile-gnutls/releases/tag/v4.0.1>. But since those tarballs are also on ftp.gnu.org, it’s okay. > We put a copy of relevant gnulib files in guile-gnutls's git, so no > gnulib is necessary. But adding autoconf+automake as a build dependency > for everyone may not be nice (is guile-gnutls part of the guix > bootstrap? is it before autoconf/automake?), so maybe there is some > utility in publishing curated tarballs for some time still. Actually you’re right: Guix currently requires a tarball for bootstrapping reasons. > The migration re-created the master branch, but I pushed it as main now. > I'm not sure we should remove the master branch? We can just stop push > to it. Yes, it’s probably best to remove the ‘master’ branch and make ‘main’ the default. Thank you for all this!! Ludo’. _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
