[asdf-devel] New ASDF maintainer sought

[Vsevolod Dyomkin]

On Sun, Sep 12, 2010 at 10:22 PM, Robert Goldman <rpgoldman at sift.info>wrote:

> On 9/12/10 Sep 12 -1:55 PM, Vsevolod Dyomkin wrote:
> > On Sun, Sep 12, 2010 at 8:09 PM, Robert Goldman <rpgoldman at sift.info
> > <mailto:rpgoldman at sift.info>> wrote:
> >
> >     On 9/12/10 Sep 12 -11:48 AM, Vsevolod Dyomkin wrote:
> >     > Hi,
> >
> >     Some random comments....
> >
> ....
> >     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.
>
> I don't believe that is correct.  Here is a line I have ripped from
> version-satisfies-p, which seems to clearly show that 2.103 is (2 103)
> not (2 1 3):
>
> ASDF(76): (mapcar #'parse-integer
>                   (split-string "2.103" :separator "."))
> (2 103)
>

And that is what's annoying, since actually (semantically) 103 is meant as
1.3, no?


>
>
>
> >
> >
> >
> >     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.
>
> I certainly hope you are wrong in thinking this won't change, but fine.
>
> I think we are still going to want a release policy for ASDF 3 and ASDF
> 2 separately, with the ASDF API being stable over ASDF 2 releases.
>
> >     > - 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> <http://common-lisp.net>)
> >
> >     Is there some reason that common-lisp.net <http://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.
>
> I am just feeling the need for some stability, having been through CVS
> and git already (and the git transition was pretty bumpy). Getting all
> the information OUT of launchpad and into a different issue tracker
> seems painful.  However, if someone wants to take the trouble of
> actually porting all the launchpad data, who am I to object?
>
> Best,
> r
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100912/a7763378/attachment.html>