[gnutls-help] guile-gnutls copy at codeberg

[Simon Josefsson]

Ludovic Courtès <ludo at gnu.org> writes:

>> 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. :-)

The above is actually a paid gitlab group. Gratis gitlab CI cycles have
been reduced to an unusable minimum.  I see no other choice until we get
reliable Woodpecker CI up and running, I don't feel comfortable making
any changes without regression testing...  Even with woodpecker the
gitlab CI may still be useful, just like the many github CI projects for
GNU projects provide good QA coverage.

>>> 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>.

I opened https://codeberg.org/Codeberg/Community/issues/2031 about that.

> But since those tarballs are also on ftp.gnu.org, it’s okay.

I wonder if these codeberg release page provide value.  They take some
manual time to prepare...  maybe we should just disable it.  OTOH, I
like having redundancy for tarball distribution, and using gnu.org's
gnutls area seems a bit weird too.  Maybe the release pages can be
automatically populated from the git tag somehow.  I'll continue use it
to gain experience with it.  At least the URLs are predictable, and
hopefully even discoverable automatically?  Like this one:

https://codeberg.org/guile-gnutls/guile-gnutls/releases/download/v5.0.1/guile-gnutls-5.0.1.tar.gz

>> 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.

Is it possible to relax that to use a tarball of the git content
instead?  Then autoconf, automake, libtool, and maybe some more like
texinfo will be required.  Or would that create a bootstrapping
dependency bloat problem?  How to tell?

Updating Guix to use latest guile-gnutls would be good too...

>> 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.

Removing the 'master' branch automatically closed all open merge
requests that were migrated from gitlab.  We only had two open requests,
and Dariqq quickly opened new merge requests on codeberg, so I think we
are good, but it may be worth remembering for other migrations.  Old
merge requests may become broken if there is no 'master' branch too.  It
would be nice if gitlab->codeberg migration process could have an option
to rename branches like 'master' -> 'main'...

https://codeberg.org/Codeberg/Community/issues/2032

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20250719/7d2f10f1/attachment.sig>