Re: [Ecls-list] [maintainership]
Oh thank god it was awful to try recover my old sf account, I'll fix tmrrw. In the meantime to make ecl work I need to apply patches to bdwgc, libatomic ops, libgmp. Currently first two are included in. So we can do git submodule and update ecl to use latest. If you are unsure about stability I guess we can fix it to a tag, not sure how to do yet. This obviously requires patches to go into main repos of bdwgc so I'll ask to Sylvain if this is OK. I don't how to handle gmp case though. I'll ask to dev list. Let me know what you think, evrim. On Feb 23, 2015 6:34 PM, Daniel Kochmański jackdan...@hellsgate.pl wrote: Hey, As I already noted, development moved to gitorious - so adding to sourceforge project (what I did), doesn't give you permission to push to repository. Please create gitorious account and I'll add you to collaborators right away. Project address is: https://gitorious.org/embeddable-common-lisp and ECL repository address is: https://gitorious.org/embeddable-common-lisp I'm going to write something more this week about new branching model - in shourtcut - everything in-development lands in develop branch, and each push to master is equal to new release. More on fixes topic - great job and thank you. Could you also remove trailing whitespaces from the second patch of yours regarding stack direction? Best regards, Daniel Evrim Ulu writes: Hello, this tests are very nice. Anyway, I've fixed autotools finally. Here is the patch: https://github.com/evrim/ecl-mobile/commit/7db27861a6c3cdb8407a3c834f797f918d89ed32 My sf account is evrimulu. If you provide me write access, i'll glad to push it. evrim. On Sun, Feb 22, 2015 at 9:34 PM, Daniel Kochmański jackdan...@hellsgate.pl wrote: Hello, Anton Vodonosov writes: Hello Daniel, My main wish to you: the most important criterion - don't break ECL, don't make it worse than it is today. Thank you. I do agree, it's most important case and my greatest concern about whole thing. And thanks for your initiative to take care about the project. From your list of goals, I think new release is the most important, because HEAD is quite different from the last release. Juan Jose didn't released his last changes, so probably the HEAD is in some work-in progress state. I can help with testing using cl-test-grid - we build all the libraries from quicklisp on old release, and with new release and compare results to detect regressions, like this: https://common-lisp.net/project/cl-test-grid/ecl/ecl-diff-2-lisp-to-c.html Thank you. I saw you already submitted some test results. I'll take a closer look at whole procedure as next thing. BR, Daniel ps. sorry for resend - i had problems with mu4e configuration (wrong e-mail sender address, and mail didn't came through to mailing list). 21.02.2015, 09:51, Daniel Kochmański jackdan...@hellsgate.pl: Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. Best regards, Daniel Juan Jose Garcia-Ripoll writes: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
Hello, Anton Vodonosov writes: Hello Daniel, My main wish to you: the most important criterion - don't break ECL, don't make it worse than it is today. Thank you. I do agree, it's most important case and my greatest concern about whole thing. And thanks for your initiative to take care about the project. From your list of goals, I think new release is the most important, because HEAD is quite different from the last release. Juan Jose didn't released his last changes, so probably the HEAD is in some work-in progress state. I can help with testing using cl-test-grid - we build all the libraries from quicklisp on old release, and with new release and compare results to detect regressions, like this: https://common-lisp.net/project/cl-test-grid/ecl/ecl-diff-2-lisp-to-c.html Thank you. I saw you already submitted some test results. I'll take a closer look at whole procedure as next thing. BR, Daniel ps. sorry for resend - i had problems with mu4e configuration (wrong e-mail sender address, and mail didn't came through to mailing list). 21.02.2015, 09:51, Daniel Kochmański jackdan...@hellsgate.pl: Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. Best regards, Daniel Juan Jose Garcia-Ripoll writes: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
On Sat, Feb 21, 2015 at 11:57 PM, Daniel Kochmański jackdan...@hellsgate.pl wrote: Also, is anyone aware, how to edit ecls.sourceforge.net site? (it's different then site accessed with SF search). http://sourceforge.net/p/forge/documentation/Project%20Web%20Services/ and http://sourceforge.net/p/forge/documentation/Release%20Files%20for%20Download/ -- With best regards, Stas. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [maintainership]
Daniel Kochmanski wrote: Also, is anyone aware, how to edit ecls.sourceforge.net site? (it's different then site accessed with SF search). Do not know specifically about ecl, but AFAICS this is project web space offered to all projects. You edit locally and download to SF. Download instructions are in full SF doc. -- Waldek Hebisch hebi...@math.uni.wroc.pl -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [maintainership]
Hi, Stas Boukarev writes: Daniel Kochmański jackdan...@hellsgate.pl writes: Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. I added you to the admin team on sourceforge. Thank you. I've rolled new / git-head release (more details on ECL post). -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel Be the change that you wish to see in the world. - Mahatma Gandhi -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [maintainership]
Also, is anyone aware, how to edit ecls.sourceforge.net site? (it's different then site accessed with SF search). Daniel Kochmański writes: Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. Best regards, Daniel Juan Jose Garcia-Ripoll writes: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
Hello Daniel, My main wish to you: the most important criterion - don't break ECL, don't make it worse than it is today. And thanks for your initiative to take care about the project. From your list of goals, I think new release is the most important, because HEAD is quite different from the last release. Juan Jose didn't released his last changes, so probably the HEAD is in some work-in progress state. I can help with testing using cl-test-grid - we build all the libraries from quicklisp on old release, and with new release and compare results to detect regressions, like this: https://common-lisp.net/project/cl-test-grid/ecl/ecl-diff-2-lisp-to-c.html 21.02.2015, 09:51, Daniel Kochmański jackdan...@hellsgate.pl: Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. Best regards, Daniel Juan Jose Garcia-Ripoll writes: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
Hello, it's saturday and nobody has risen concerns about new maintainership, so I assume it's ok with you all - thanks for putting trust on unknown person. For start I need admin privileges on SF, and on wikispaces (which also requires subscription renewal). My user name on both portals is dkochmanski. Best regards, Daniel Juan Jose Garcia-Ripoll writes: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
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 jackdan...@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 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [maintainership]
I think this is a wonderful idea and would love to see Daniel take over the project. As a very long time ECL user (since version .02 as I recall) who has pretty much lurked here on the list, but quietly used ECL for a long time, I've been very saddened to see ECL stagnate. I would love to see this project get some new blood in it and I'd also be willing to offer my help if I can get some free time in the future. But at this time, I wanted to voice my support of Daniel as a new maintainer. Although I don't know you sir, you seem to have great ideas and I look forward to seeing some new life in ECL. Thank you. Michael On 02/15/2015 02:55 PM, Daniel Kochmański wrote: 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
Re: [Ecls-list] [maintainership]
Sorry for not having been active, including on this list. On Sun, 15 Feb 2015 21:55:20 +0100 Daniel Kochmański jackdan...@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 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [maintainership]
Hello, Evrim Ulu writes: Count me in too, that's great :-) I've started fixing the autoconf script, i'll try to merge Sylvain's patches into the repo. I tried to consult patch-queue, to check, if you refer some of patches there, but SourceForge seems down. What patches do you have in mind? Feel free to join at https://github.com/evrim/ecl-mobile/branches I'm working on mobile branch but its obvious that i need to fix generic things first. evrim. On Mon, Feb 16, 2015 at 7:15 AM, Hernan Ezequiel Di Giorgi hernan.digio...@gmail.com wrote: I definitively want to help. I tried to port the ECL build system in the past to CMAKE, but i drop it. Also i create a nice repl with ECL for android, https://play.google.com/store/apps/details?id=ar.com.playnu.clrepl. I programmed all my life as programmer in C and C++. That's good news. Compilation guide for ECL against bionic would be nice thing. If it's free software, you could put clrepl it on FreeDroid repository as well. I studied the source the last month, so i could be ready to help. About the point 2. Why not github? Is seems more social and popular. I'm more into gitorious, since it more focuses on projects, not on people, but I have no problem with github as well. Github better exposes issues interface and fork/merge utilities, so after short reconsideration I think it's better idea. And no separate the libffi, gmp, and leave them to can get only one shared library when compiling, what is specially nice when working with android. I'm not sure, what do you mean? It would be no functionality split, but rather separation of different projects. (: 2015-02-15 18:13 GMT-03:00 ZhanLin Shang shangzhan...@gmail.com: Hi Juanjo, I think we would need a well-organized document (including examples) to make others know ECL well. I can help to translate the documents into Chinese :) Best Z.Shang On Sun Feb 15 2015 at 9:08:51 PM Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo Thank you, I'll drop you an e-mail in a few days with update. On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang Your help is appreciated and welcome. I think it is best to wait until Saturday to gather more opinions and discuss whole thing. Best regards, Daniel On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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.
Re: [Ecls-list] [maintainership]
Count me in too, I've started fixing the autoconf script, i'll try to merge Sylvain's patches into the repo. Feel free to join at https://github.com/evrim/ecl-mobile/branches I'm working on mobile branch but its obvious that i need to fix generic things first. evrim. On Mon, Feb 16, 2015 at 7:15 AM, Hernan Ezequiel Di Giorgi hernan.digio...@gmail.com wrote: I definitively want to help. I tried to port the ECL build system in the past to CMAKE, but i drop it. Also i create a nice repl with ECL for android, https://play.google.com/store/apps/details?id=ar.com.playnu.clrepl. I programmed all my life as programmer in C and C++. I studied the source the last month, so i could be ready to help. About the point 2. Why not github? Is seems more social and popular. And no separate the libffi, gmp, and leave them to can get only one shared library when compiling, what is specially nice when working with android. (: 2015-02-15 18:13 GMT-03:00 ZhanLin Shang shangzhan...@gmail.com: Hi Juanjo, I think we would need a well-organized document (including examples) to make others know ECL well. I can help to translate the documents into Chinese :) Best Z.Shang On Sun Feb 15 2015 at 9:08:51 PM Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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/ -
[Ecls-list] [maintainership]
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
Re: [Ecls-list] [maintainership]
Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
Re: [Ecls-list] [maintainership]
I definitively want to help. I tried to port the ECL build system in the past to CMAKE, but i drop it. Also i create a nice repl with ECL for android, https://play.google.com/store/apps/details?id=ar.com.playnu.clrepl. I programmed all my life as programmer in C and C++. I studied the source the last month, so i could be ready to help. About the point 2. Why not github? Is seems more social and popular. And no separate the libffi, gmp, and leave them to can get only one shared library when compiling, what is specially nice when working with android. (: 2015-02-15 18:13 GMT-03:00 ZhanLin Shang shangzhan...@gmail.com: Hi Juanjo, I think we would need a well-organized document (including examples) to make others know ECL well. I can help to translate the documents into Chinese :) Best Z.Shang On Sun Feb 15 2015 at 9:08:51 PM Juan Jose Garcia-Ripoll juanjose.garciarip...@gmail.com wrote: Dear all, first of all thanks for taking me into consideration and for volunteering to continue the project. I was overoptimistic in assuming that I could even continue fixing bugs or reading the mailing list at all. I therefore welcome any initiative to have a stable team that works on bugs and keeps the project alive and useful. Just let me know what you need, such as adding you to the Admin list and perhaps updating or giving you access to other resources. Since I do not have much time to read these threads, I would appreciate a warning when the issue has been settled by the community, with a list of steps that I should take. Best regards Juanjo On Sun, Feb 15, 2015 at 10:00 PM, ZhanLin Shang shangzhan...@gmail.com wrote: Hi Daniel, I agree with your opinion, I know some C (I've been playing around with C for 5 years but not embedding) and some CL (which is the language I use the most), I will try to help if I can. Best, Z.Shang On Sun Feb 15 2015 at 8:56:01 PM Daniel Kochmański jackdan...@hellsgate.pl wrote: 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
