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:
- We should probably have a definition of "rational version policy,"
at least by citation.
http://docs.rubygems.org/read/chapter/7
- 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.
- 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
This sounds great.
Best, Robert
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel