Ludovic Courtès <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
