RFS: Please upload cl-asdf package

[Faré]

> 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-mentors at lists.debian.org,
  with Cc: pkg-common-lisp-devel at 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