> I have read a lot, checked the Makefile and your minimakefile branch. > I still don't feel self-confident enough to say "I know how to do it" > The minimakefile branch is where the action is, and you need to update it, with e.g. git pull --rebase
> Following the comment in release: > >> (defun release () >> "Release the code (not implemented)" >> #| RELEASE or PUSH checklist: >> make test-all > It has been much enhanced since. Not that this function interleaves the debian and non-debian aspects of the release. For a debian-only package, just (1) git branch release (2) edit debian/ directory if needed, and commit use commit --amend and tag -d if needed (but only amend commits you haven't published). (3) make debian-package; unless success, goto (2) (5) run lintian ../*.changes; unless success, goto (2) (6) make publish-debian-package (7) Check the lintian report from mentors; unless success, goto (2) (8) on success, push the code to git upstream (9) send an RFS to debian-ment...@lists.debian.org, with Cc: pkg-common-lisp-devel@lists.alioth.debian.org The first thing you'll need to edit is the control file, to add your email to the Uploaders: (one that corresponds to the PGP key that your registered to mentors.debian.net). The second thing will be making sure there's a new changelog entry that follows the proper format bears your signature. parse-changelog and lintian can help you get it right, as well as the suitable emacs mode. > which implementations (at which versions) do you test with? > It's now *default-test-lisps* and my override on my laptop is export ASDF_TEST_LISPS="ccl clisp sbcl ecl ecl_bytecodes cmucl allegro lispworks mkcl abcl allegromodern xcl gcl" using recentish (a few months old at worst) versions of all of them. As far as debian packaging goes, you can assume that portability issues have been solved by other people, and you should probably test using whichever implementations are packaged with debian, plus whichever you also use. >> ./test/run-tests.sh -c abcl > > but the last line hangs since several hours on an i7 2.9 GHz. Although > abcl is described as 'damn slow' in run-tests.sh, I guess it is usually > not /that/ slow. What would be the next step? Contact the maintainers? > I' getting rid of run-tests.sh in the minimakefile branch, but -c is test-clean-load, which should only take a few seconds. Remarkably, there was a bug in the minimakefile branch, that I just fixed, whereby I forgot to (asdf-test::verbose nil) before to load asdf. But that doesn't explain your failure, that happened in the master branch. >> make test-load-systems s=fare-all > > Is fare-all one of your libs? I couldn't find any pointer to it, neither > on your github page, nor using different search engines. > It's an empty system that depends on a truckload of other systems that I use, which, when I don't forget to test them, avoid embarrassment when Xach tells me that some library modification I made broke another system. > I saw that the debian/changelog entries are very detailed and contain > more information than one could deduce from the commit messages. Is the > debian/changelog file maintained during the development cycle by the > committers? > Historically I've used the debian/changelog in lieu of a non-debian changelog since I was maintainer of both and it simplified things for me. You'll have to negotiate how things will go in the future with the maintainer Robert Goldman, who may or may not continue this practice. > How often are the following steps performed? When the minor version > increases, or also when the patch version increases? > Since you'll be debian maintainer but not upstream maintainer, your loop would be slightly different (see my nine steps above). The good time to build a debian package is right after a stable release (in the release branch), or right after a fix to an embarrassing bug that cripples the previous debian package (in the master branch). >> send announcement to asdf-announce, asdf-devel, etc. >> Move all fixed bugs from Fix Committed -> Fix Released on launchpad > > are performed by the release managers. How is the timing of the steps, > e.g. when I'm on vacation, would I have to be available for my 'duties', > when a release is planned? > These are for the upstream maintainer. I suggest you rehearse all the steps except pushing and publishing, and make sure all the code you need is committed in the master branch before the next release (in a few months). It's not hard, but it does require getting familiar with the tools. The new code in the minimakefile branch should make it easier, but you may have to tweak it to your exact needs. Best regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politics is the only profession that does without learning, probably because those who suffer from mistakes are not the same as those who make them. — Achille Tournier, Pensées d'automne _______________________________________________ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
