[gnutls-help] Guile-Gnutls bindings to separate git repo?

[Simon Josefsson]

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

>> git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
>> cd guile-gnutls/
>> git-filter-repo --path configure.ac --path .gitignore --path
>> doc/.gitignore --path README.md --path doc/ --path guile/ --path
>> Makefile.am  --path m4/guile.m4 --path NEWS
>> git remote add guile-gnutls git at gitlab.com:jas/guile-gnutls.git
>> git push -u guile-gnutls --all
>> git push -u guile-gnutls --tags
>
> I wonder if we should omit NEWS as it blurs the history a bit, in which
> case we’d later add a new NEWS file.

My thinking is that we should include NEWS and then trim down it to
become a guile-only NEWS file, and having the history of the old big
NEWS file in guile-gnutls's git repository preserves the older history
in case our trimming trims too much.  Does this make sense?

>> Is this a suitable base to start on?  Maybe we can iterate a couple of
>> times to get a suitable setup, I think we should prune some more in
>> doc/ which according to git-filter-repo man pages should be done by
>> another run of it to prune the repository further.  Getting a top-level
>> configure.ac and Makefile.am is a main work item here.
>
> Yes, in doc/ we only need gnutls-guile.texi, gnutls.texi (of which
> gnutls-guile.texi was extracted) and Makefile.am I think.

Right, I'll do another iteration cleaning out doc/ too.

>> Compared to the above setup, we may want to rename guile/ into
>> gnutls/.
>
> Or move guile/ to the top level, but maybe that can be done in a later
> commit.

I prefer having the top-level directory to be mostly maintainer stuff
like text files and build tools, so the source code is more clearly
separated.

>> One question is about version numbers.. it should probably have its own
>> version number, right?  Would starting at 0.0.0 be a problem for
>> packaging, or should we start with 3.7.8 (upstream gnutls version) and
>> then count upwards (separate from GnuTLS versions) from there?  I
>> prefer starting with 0.0.0 and using semantic versioning from the
>> start.
>
> That’s a good question.  I would tend to start at 1.0.0 (because it’s
> stable).  However some distros, such as Debian, have a binary package
> called ‘guile-gnutls’ that’s currently at 3.7.x, so the version number
> may cause them trouble.  I don’t know whether we should take that into
> consideration or leave it up to distros.

They can always do an epoch if necessary.  I think doing a standalone
guile-gnutls 3.7.8 as quickly as possible and then a 4.0.0 to mark that
versioning is now independent makes sense.  We wouldn't want to couple
guile-gnutls versioning with GnuTLS versioning too tightly.  On the
other hand, maybe we could match guile-gnutls MAJOR.MINOR to the latest
upstream GnuTLS MAJOR.MINOR so the API-versioning becomes clear?

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