Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0

[Gregory Wright]

Hi Camm,


On Wed, 2002-08-14 at 18:11, Camm Maguire wrote:

> > > Gregory Wright <address@hidden> writes:
> > > 
> > > Is this really true?  I thought that the whole idea of keeping the
> > > LISP alongside the COMMON-LISP was to allow both to coexist for
> > > backward compatibility purposes?  There are a few core C functions
> > > which have to be written in one way *or* the other, as far as I can
> > > see, but apart from these few, it appears as if we should be able to
> > > have both functionalities in one image.  That is not to say it is
> > > necessarily desirable, just possible, right?
> > > 
> > 
> > It's certainly possible---perhaps I spoke too soon that LISP should go
> > away. However, it might be a good idea to rename it so that people who
> > use it know what they're getting into, i.e., not ANSI CL, not even
> > CLtL2, but something much closers to CLtL1. Perhaps LISP-GCL? (We could
> > compell the treatment of LISP-GCL as LISP as a start-up option.)
> > 
> > I guess I favor the approach


> 
> Did you have something you wanted to finish here?  In any case, I'm ok
> with renaming the current LISP package if that works for everyone.

I just wanted to say that I favored (post-2.5.x) making the right thing
easy (ANSI by default) and backward compatibility something you have to
deliberately turn on. Just to cut down on confusion and spurious
problems.  


 
> >     3. Version control by #ifdef is a nightmare.
> > 
> > The problem is that it takes incredible care and discipline to make it
> > work. It could be done---you allow yourself just one kind of
> > conditional, #ifdef GCL_ANSI ... #elif GCL_TRAD .. #else ... #endif, so
> > you really have two different codebases living in the same tree. It is
> > essential to avoid debugging interactions between the two. No software
> > project has time for that sort of thing.
> > 
> 
> This is a very useful comment, raising an issue which I haven't fully
> considered.  In any case, I wouldn't want more than one
> ANSI_COMMON_LISP C macro.  In fact, at some point I'd ideally love to
> find time to clean out crufty old macros.  They should only be used
> for portability issues in my mind, not features.  Features can be
> toggled, however, via configure, which in essence would optionally run
> 'make' in certain subdirectories extending the saved image, much in
> the way --enable-ansi works now.  Rigorously following this pattern is
> not so easy, as we already have C macros supporting readline, bfd,
> gmp, etc.  I've tried not to forcibly shift everyone over the new
> stuff if they still need the old, e.g. Windows and relocations.
> Hopefully by release time we'll be able to thin out the options.  I
> must confess, though, that this is the first software project of this
> sort I've ever managed, and I really don't know what the best thing to
> do is in many cases.  Your experience here is very helpful.
> 
> >     4. Instead of asking, how do we get gcl to support ansi, we
> >        should ask what essential features would an ANSI gcl need to 
> >        keep the 'customer's' existing code running?
> > 
> > Here's a scenario: the work to get GCL to build on all the debian
> > platforms wraps up. GCL builds maxima and ACL2 on all platforms. Tag
> > this as 2.5.0_release_candidate. Fix the bugs and then release. At the
> > release, branch the cvs. The 2.5.0 branch only gets bugfixes. The main
> > branch is developed with the goal of releasing a mostly much ANSI 3.0
> > that builds on all platforms. Perhaps we could allow a runtime option to
> > turn on traditional feature (like gcc's -traditional). But no guarantees
> > are made with respect to traditional behavior.
> > 
> 
> I like this in general.  I'll try to have time to dig out our old
> discussion of gcl's roadmap, updating it for the progress thus far,
> and making clear what we feel we must have before release.  The
> portability stuff is one, but there are quite a few other mundane
> tasks, like license checking, adding missing documentation, etc.
> Feedback here most appreciated!
> 

I guess my point is here that beyond a roadmap, we need a release
engineering policy. It doesn't have to be fancy, just, "After we finish
items 1, 2 and 3 we'll make a beta release" or deciding when to make a
new stable branch. For example, switching to a new stable branch usually
means that bugs on the old stable are ignored, unless they are
reproducable on the new stable.


We should have just one stable branch, and one development branch. Bug
fixes on stable are amost always merged to development, but seldom the
other way. The goal is to not break the stable by patching it too much.


Since the todo list is long, we should probably look at several interim
releases. We can label them 'alpha', 'beta' or 'thrillseekers only', but
by making more frequent releases we'll raise the visibility of the
project and likely get more feedback.


Here's a proposal, based on the roadmap discussion from May. I welcome
discussion and the best way to get it going is to propose something
specific.

1. For 2.5.0-alpha:

        Clean build on all debian platforms with -Wall.
        libbfd issues resolved on all platforms (even if that
        means libbfd won't be supported on that platform).

        We define a regression test that all builds must pass
        (build maxima and ACL2 + tests cleanly on all platforms?)

When we get the cvs HEAD to a 2.5.0-alpha state, we open a 2.5 branch.

2. For 2.5.0-beta:

        Licensing checks
        Make sure bignum arithmetic works on all platforms.
        Code freeze on this branch except for bugfixes.

3. For 2.5.0-release_candidate:

        Everything done but documentation (this is sour chance to sync
        up the documentation with all the work that has gone before).

4. Release 2.5.0

        Release with documentation.
        2.4.x will be deprecated; users urged to upgrade to 2.5.x.

5. Fix the obvious 2.5 bug that releasing roots out.

6. HEAD starts toward 3.0, ANSI compliant GCL

        Define which ANSI tests we will require GCL pass (really,
        this means understand the test suites).

7. Intermediate goal: COMMON-LISP skeleton complete

        Every symbol in the COMMON-LISP package has skeleton
        support (the right arguments) even if it doesn't work yet.

8. Intermediate goal: COMMON-LISP core complete

        Almost everything in COMMON-LISP almost works.


9. Intermediate goal: Modernize the build system

        Use modern automake/autoconf setup. May break compatibility
        with autoconf-2.13 and earlier (but 2.5.x should still build
        with older autoconfs).

10. 3.0-alpha release

        Feature complete.
        branch the cvs



When we see how that's going we could set specific goal dates for alpha,
beta and release_candidate builds.

Naturally, a plan like this gets fuzzier as it extrapolates into the
future. Items 7, 8 and 9 involve a lot of parallel work.

Goals and especially release target dates are good because they help us
decide what has to be done and what can wait. If we can get this plan
into good shape, we can start asking what dates could go onto items 1, 2
and 3.

> 
> > I'm certainly trying to encourage us all to look at what we can possibly
> > avoid doing. Our company's software team is about the same size as
> > gcl's. We have to be pretty ruthless in deciding what really needs to be
> > done. Ars longa, vita brevis!
> > 
> 
> I agree whole-heartedly and love this new phrase!
> 

Best Wishes,
Greg


-- 

Gregory Wright
Chief Technical Officer
PacketStorm Communications, Inc.
20 Meridian Road
Eatontown, New Jersey 07724

1 732 544-2434 ext. 206
1 732 544-2437 [fax]
address@hidden