[Ecls-list] [maintainership]

[Matthew Mondor]

Sorry for not having been active, including on this list.


On Sun, 15 Feb 2015 21:55:20 +0100
Daniel Kochmański <jackdaniel at hellsgate.pl> wrote:

> most of you have probably noticed, that ECL is unmaintained for quite a
> while. Some spontaneous attempts are made, like submitting a patch, or
> answering question - what is great, but insufficient. Many important bug
> fixes last on git head, a few potential improvements wait in patch
> queue. The other words - ECL starts to smell funny, what's a shame,
> since it's a great project.

Earlier on this list archives I also have a TODO which might perhaps
serve as inspiration (I could possibly attempt to find it).

Unfortunately, some changes made to ECL broke some of my code (most
notably the conformance fix for strings, which is suboptimal to work
with C FFI; actually some of ECL's code broke too with this change),
and since I have no time to develop proper solutions to the problem
(like good ideas derived from CLISP as previously discussed with PJB), I
consider my personal copy as a fork already.  Although I still use ECL
actively (that fork at least), I'm unlikely to have time to help soon,
I'm sorry about that.

An issue also made me reconsider ECL for future projects, but this has
more to do with boehm-gc bugs on NetBSD (heap growing bugs when
multithreaded) than with ECL itself, and I've not have had time to
seriously look at it either, but know some workarounds like not using
stdio and initially growing the heap.

Previously we had decided to remain on SF when previous maintainership
changed, and I don't think that SF is what prevents development; but
since as I previously said I won't be able to help in a decent amount
of time, feel free to move the project elsewhere if other active
members agree.  Please make a clear announcement here about where to
locate the new resources (mailing list, repository, problem reports),
if/when moving.  I would also suggest to ensure that an archive of this
mailing list remain if possible (as necessary keeping the ECL project
on SF with clear information that it's deprecated and where to find it
officially).

As for swank, I'm not sure it should be part of ECL, that comes with
third-party SLIME, and there are no established API versions for
guarenteed compatibility between the two when upgrading one of the
parts.  To me, ASDF and QuickLisp are also third-party and I don't use
them, but it would make sense for them to be supported natively, if
only to make ECL more popular and easy to use.  The ECL-provided
libgmp, libffi and libgc probably include portability fixes, although I
personally don't use them anymore either (building ECL to depend on
OS/package-installed ones instead).  I suspect that if ECL binary
builds were supported and distributed, it might be a good thing to keep
them around and update them as necessary.

There also was the previous discussion on LGPLv3, which allows
relicensing under GPLv3 or AGPLv3.  It however does not seem to be a
problem unless the official ECL itself decided to change its license.
The project already depending on libraries under the LGPL variants, a
less restricted license such as MIT/BSDL would not make much difference
for ECL; upgrading to LGPLv3 might be the best choice.  Please don't
choose the GPLv3 or AGPLv3 for the official project however, which
would be counterproductive to the way ECL is intended/designed to be
used.

Thanks,
-- 
Matt