[Ecls-list] [maintainership]

[Daniel Kochmański]

Hello,

Matthew Mondor writes:

> 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).

I would appreciate it. Even if I have few ideas by myself, it would
point me to some more crucial changes on the list, which I haven't
anticipated.
>
> 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.

Could you share your personal fork along with shortage of your
discussion?
>
> 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).

I do agree that it would be a shame to just drop resources. SF has
downs, and apparently we have two versions of page (one accessible via
SF search, and one under address ecls.sourceforge.net. I think it's bad,
especially when they present different news set.
>
> 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.

Regarding libgmp, libffi and libgc - I think we need to keep it, but as
separate repositories attached to project (present in source tarballs
tough).
>
> 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.

That goes in line with my personal opinion.
>
> Thanks,

Thank you for sharing your thoughts,
Daniel

-- 
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel

"Be the change that you wish to see in the world." - Mahatma Gandhi