[gnutls-help] guile-gnutls copy at codeberg

[Simon Josefsson]

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

>> https://codeberg.org/guile-gnutls/guile-gnutls
>
> I would support such a move.
...
> IMO you have all the authority to do it!

Thank you!

> I would suggest migrating the project (including issues and PRs): it’s
> a super easy and mostly lossless process with Codeberg.  I think you’ll
> first need to delete this repo and then click on “+” in the blue banner
> at the top and then “New migration”.

Done!

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.

>> - GitLab Pipelines - this is a very important QA tool and I wouldn't
>>   want to release anything without having all those tests.  So whatever
>>   we do, the GitLab CI/CD will be important for some time still.  I
>>   don't speak Forgejo CI/CD but will try to learn, but it appears far
>>   behind GitLab CI/CD feature-wise.  I don't see any problem having a
>>   GitLab read-only mirror project for CI/CD purposes, I do that for some
>>   other projects without GitLab presence.
>
> Yeah, that I don’t know.  There’s the integrated Woodpecker CI but I’ve
> never used it.

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.

I wonder if codeberg merge requests can be thought to point or use
GitLab CI/CD status, but I don't think this is important.

>> - GitLab release pages - I've been using this feature as a learning
>>   excercise, but I'm not sure how important it is.  I guess codeberg has
>>   something similar.  I find these pages rather ugly, and prefer old
>>   school HTTPS/FTP publication with stable URLs and a mirror network.
>>   Savannah and ftp.gnu.org provides this, and we can continue use that
>>   (or not).
>
> 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.

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.

>> Btw, I pushed a copy of GitLab 'master' branch to a 'main' branch on
>> Codeberg since it seemed like a nice time to change branch name too.
>
> Agreed.

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.

/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/20250711/9dd0c996/attachment-0001.sig>