On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman <rpgold...@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. > http://docs.rubygems.org/read/chapter/7 > > 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 > > This sounds great. > > Best, > Robert > > _______________________________________________ > asdf-devel mailing list > asdf-devel@common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel >
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel