On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman
<rpgoldman@sift.info> wrote:
On 9/12/10 Sep 12 -11:48 AM, Vsevolod Dyomkin wrote:
> Hi,
Some random comments....
>
> I have spent some time this year familiarizing myself with ASDF, and
> afterwards I think, that it's a great build-tool (possibly, the best one
> around, actually), which has a lot of hidden potential. So I'd be
> willing to help as the maintainer or one of the maintainers.
>
....
>
> As a Release manager I'd do the following:
> - establish a regular release cycle (bi-monthly), transition to follow
> the Rational version policy
Three points with respect to this:
1. We should probably have a definition of "rational version policy,"
at least by citation.
2. If the rational version policy is the numbering scheme I found by
googling, I don't believe it is compatible with asdf:version-satisfies.
I would suggest we avoid adopting a policy that doesn't meet that
constraint.
Last time I looked, version-satisfies quite-happily handled exact versions, like "1.2.3", which also comply with the "rational" policy. At the same time, current versions, like 2.103 are actually 2.1.3 in disguise, which is a little annoying. Yet, the biggest benefit of the rational policy (or at least some policy) is that it's predictable.
3. Is this bi-monthly release policy wrt ASDF 3? In my fondest dreams
ASDF2 is getting stable and the ASDF 2 release cycle should be "very
rarely, never in the limit." I say this not just because I am looking
forward to ASDF 2 being done, but also because ASDF is critically
foundational to the entire open source CL community. In order for
members of this community to be able to share work, ASDF's API needs to
be very, very stable (see the paper Faré and I wrote about ASDF 2
development for a more thorough presentation of the need for stability).
Rarely a release should break backwards compatibility. But from what I see now, there's quite a lot of fixes to ASDF (at least a couple each month), and I don't forsee the change to such situation.
> - finish creating a comprehensive test-suite, and organize some
> automatic testing process
This would be very good. BTW, I have just discovered that there are at
least three different ways to start CCL, and only one of them is
currently exercised by our test suite.
> - move development to github, where there is some rather
> convenient infrastructure, like issue tracking (leaving a mirror on
> common-lisp.net <http://common-lisp.net>)
Is there some reason that common-lisp.net + launchpad is unsatisfactory?
It's much less integrated and more clumsy (I filed several bugs through launchpad myself and don't like the experience). It seems, that github is a much friendlier place for that, and it is developing pretty fast. Yet, I don't think, that it is critical, so if other contributors would like to stay with the current variant, I don't object.
> - work on improving documentation (also I'm currently doing a series of
> articles about ASDF in Russian in my blog
>
http://lisp-univ-etc.blogspot.com, that I'm also going to translate to
> English eventually)
> - continue work on separating ASDF itself and some support subsystems
> - establish some basic contribution guidelines
> - answer questions in the mailing list
> - contribute to bug-fixing
Best,
Robert