[Ecls-list] Getting things going

[Jon Boone]

I'm good with this.  My sourceforge account id is ipmonger.

--jon

On 2013-10-21, at 08:51, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> I am sorry for the prolonged silence. I wanted to give some time for my message to settle in the community, but since I have seen a lot of interesting discussion we should make use of this momentum to get something going.
> 
> According to different private emails that I have received, a possible reconfiguration of the project would look as follows:
> Dmitri Hrapof, maintainer
> Jon Boone, supporting developer (Common Lisp)
> Matthew Mondor, supporting developer (NetBSD / Linux)
> Juanjo García Ripoll, supporting developer
> Plus whoever wants to contribute more actively. In particular it would be appreciated some help on the fronts of regular automated testing and release. Note that the degree of involvement can be very minimal: it suffices that you build or work with ECL in some platform and provide feedback or patches or simply point out problems -- i.e. Android, iOS developers out there could become more involved by simply speaking up more frequently.
> 
> I just need your ok (and your account names) to redesign the project composition in SF.
> 
> Once the issue of the team is settled, to get things up and running one should make a list of what has to be done. Some ideas though:
> 
> - Priority should be to ensure that ECL is working again in all platforms and that it is release candidate. I am partially working on this, as I do not want the new life of the project to start with a broken software.
> 
> - Things that work should not be touched until momentum is gained. The compiler is quite ok as it is, and should only be fixed when regressions are found in the libraries. This said, I am willing to speak to anybody about the internals, either in this forum or by private email or skype.
> 
> - Ideas for future changes or known problems could be organized in the form of tickets, with us discussing the details below in the "forum-type" discussion that pops up. Longer issues could be arranged by email. Common-knowledge or things that you do not know about internals would be better explained in the wiki, opening a page for the topic and me and you filling in information.
> 
> - Each of us has their own interests. I have seen very interesting suggestions from Matthew Mondor here. Those things should not be neglected -- I will help you as much as I can on getting you moving on on each of those fronts. Some things that have been mentioned by different people
>   * Improved embeddability and name convention
>   * Improving on streams & input methods (utf, etc)
>   * Neglected platforms that depend on separate ports (Android, iOS)
>   * New interpreter forms (Here the work of Dr. Schfmeister will probably win whatever we think about :-)
>   * New FFI's, including C++
>   * POSIX libraries
> I believe people overestimate the time / knowledge that is needed to get things going in many of these fronts -- the UTF thing, for instance, amounts to about 50 lines of code :-)
> 
> - I am here to help you with any of the internals or questions. One very efficient way of doing that would be to assign tickets to myself on specific questions that you are not able to resolve. For that one would have to go through SF and create new categories and organize the tickets more cleanly. Alternatively we can also create email discussions.
> 
> - There are technical issues that we should work together. Multithreading is one. Right now the implementation of locks / mutexes / semaphores, etc, is based on an idea (a wait queue that implements a per-thread semaphore using signals) which I believe is solid, but is giving rise to a lot of problems in various platforms. Issues like these depend on long email conversations and technical discussions; help is welcome even from non "developers"
> 
> - Regular testing has been set up in the past using Anton's library. I can pass you the scripts. Benchmarking has also been organized using automated scripts that I can also pass you. As I said, this is one of the things where a non-developer can really help a lot by providing the infrastructure and uploading the information to some public space.
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20131021/c8e38053/attachment.html>