[asdf-devel] New ASDF maintainer sought

[Vsevolod Dyomkin]

On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman <rpgoldman at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100912/87e55ddb/attachment.html>