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