Re: guile-gnutls copy at codeberg

--===============3387259107403700857==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ludovic Court=C3=A8s <[email protected]> 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=E2=80=99s 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 =C3=A0 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=E2=80=99s 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/gui=
le-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=E2=80=99re 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=E2=80=99s probably best to remove the =E2=80=98master=E2=80=99 br=
anch and make =E2=80=98main=E2=80=99
> 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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmh7gmoUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFogjaAQD3PN/zpFB1
bkvWntqSM8U/foMESWHIAtStuN3JU6iUWAEA1BdEUyXFXKkprgjD1F4/MwsGFkUZ
bFyIdMifcb4sJAw=
=nzhy
-----END PGP SIGNATURE-----
--=-=-=--


--===============3387259107403700857==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help

--===============3387259107403700857==--