[Ecls-list] [maintainership]

[Daniel Kochmański]

Hi all,

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.

I'm writing to mailing list to volunteer myself as projects
maintainer. I'm sure there are people better suited for such role, but
since nobody asks for it, I do. Please reply to this message with
protests or support, if any. I'm full time embedded engineer with strong
C background, and solely speaking - CL new-be. Since I'm full time
worker, I can spare only a few hours a week, but I'm sure it would be
sufficient for start.

Short plan of things, which have to be done (any help welcome) - in
descendent order:

** Roll out a new release
   Many bug-fixes lie on git, and are absent on current release. It is
   really important to make a new release.

   1. Introduce new branching model
      http://nvie.com/posts/a-successful-git-branching-model/

   2. Move development to gitorious
      Split separate projects into separate repositories (libffi, gmp)

   3. Patch submissions
      I think it would be plausible to move patch submissions to
      mailing list, so they can be commented.

** Refresh
   1. Website
      I find it counter-intuitive and hard to navigate. Sitemap should
      be rearranged, and maybe even moved from SF.

   2. Materials
      Wiki's subscription is ended now. It should be brought back.
      Usage examples should be easier to find and study.
      It would be nice to have tutorials describing, how to install and
      embed ECL in project.
      
   3. Patch/feature/bug queues (as started by Arto)   
      Decide, which patches need to be merged into ECL, reject the
      rest. Same with feature requests - if something is beyond our
      reach for now, should be tagged as won't do. Bug reports should be
      checked for these already fixed, not-bugs and some which won't be
      fixed anytime soon.

   4. Actualizing ECL support libraries - libffi breaks on build for
      armv5 (new version works like a charm). It is also at least worth
      considering switching to lgpl3 (for pragmatic reasons) - this one
      requires further discussion, but first things first.

** Evolve
   1. Third party libraries
      - Use most recent libraries (asdf, quicklisp, swank, etc)
      - Treat libffi as separate project /move to more recent version/
      - Treat libgc as separate project /consider lgplv3/

   2. Make more ports
      - Android (merge patches, write nice tutorial)
      - NaCL
      - Minix

   3. Regression / testing / deployment
      - vagrant
      - automated reports
      - suggestions?

   4. ECL java application for android

============================

I already wrote similar mail to Juan Jose Garcia-Ripoll (attached as
reference), and he suggested to write to mailing list.

Best regards,
Daniel Kochmański

> Hello,
>
> my name is Daniel Kochmański, and I want to say, that I am really
> impressed by your work on Embeddable Common Lisp, and I want to thank
> you for it. I find ecl nice piece of software and consider it a great
> opportunity to learn.
>
> I'm writing to you, because I want to be maintainer of it. I have strong
> C background, and I'm learning Common Lisp, so it wouldn't be very good
> pick if project is actively developed, but since it starts to smell
> funny (pun intended), I think it won't be a bad idea. I'm full time
> embedded systems engineer, so I can spare only few hours a week, but I'm
> convinced it would be sufficient for start.
>
> First thing I'd like to do is to roll out a new release, since git head
> has many improvements over current release (especially bugfix for
> bordeaux-threads), and cleanup of feature-requests and bug-reports on
> SourceForge.
>
> Then I plan to move development to gitorious, and host third party
> libraries as separate projects. Also, branching model would change -
> current commits will land on "develop", and "master" will be kept for
> releases only. I'm also considering reorganizing, or even moving ecl
> site from SourceForge, because I find it really hard to navigate. There
> is also problem with wiki, where subscription has ended, and needs
> reactivation by one of the wiki organizers (according to wikispaces).
>
> Next thing would be actualizing libffi (build breaks on armv5 on old
> sources included with ECL), and merging patches for android and nacl
> builds - I'm working on it on my local repository lately. After that to
> attract more people, I think that would be a nice idea to make android
> app, which will bring ECL to android devices.
>
> What do you think about this proposition? I was convincing myself to
> write this mail for few weeks from now, but I'm still not sure if I
> should write to mailing list first. Anyways, again, thank you for
> keeping this project alive for so many years.
>
> Best regards,
> Daniel Kochmański
>
> --
> Daniel Kochmański | Poznań, Poland
> ;; aka jackdaniel
>
> "Be the change that you wish to see in the world." - Mahatma Gandhi
>

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

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