RE: Hmmm.... future of cons?
Nadim Khemir <[email protected]> Wed, 22 May 2002 10:37:32 +0200
| Newsgroups | gmane.comp.gnu.cons.general |
|---|---|
| Message-ID | <[email protected]> |
> -----Original Message----- > From: Gary Oberbrunner [mailto:[email protected]] > Sent: Tuesday, May 21, 2002 10:25 PM > [snip] > Sounds like what we need are: > > - all recent patches > - any doc improvements > - any fixes people have been hoarding > - Cons::Plus? Someone will need to figure the best way to integrate > this. Should we just shovel it into the release package as is, or do > something tighter? Then minutes later. > -----Original Message----- > From: Gary Oberbrunner [mailto:[email protected]] > Sent: Tuesday, May 21, 2002 11:48 PM > > OK, Doug's plan sounds good to me. No new features, just a few fixes if > anyone has them. It sounded like David Sanderson had a couple; David, > do you have fixes for those bugs or just the bug reports? > > Perhaps we could include Cons::Plus, but only in a contrib/ dir, to make > sure people get it, but we don't have to do any more work? > > -- Gary O Gary (and all the other involved), I definitively understand that you have other important things in your life and please do not take no offence in the following (it is as much for me as it is for you). When I wrote the mail that started this discussion I also had in mind branching or starting a new project. If you read the mail chronologically, you'll see that we go from: a new Con, consider Scons, fix Cons (your first mail above) to fix as little as possible and continue as we did before. We use an efficient damping filter here. Do not misunderstand me, fixing a new release integrating the minimal patches and update the web site is very good and certainly the thing to do first but it's the wrong answer to this thread "future of cons". As I said before cons is sick of "open sourceness", plus many think that it is good as it is and those persons are key persons, they know the code, the know the possibilities and the limitations and they do fine with them. Funny this reminds me of my favorite project, I have my own editor, it work fine, there are some bugs lurking around but I like it the way it is and I can always dig a bit and fix the small problems. Still when I think about it might be time to re-start it or leave it to someone else. I feel the same with Cons. Cons is good and the job you guys did is great but we must think future so here are my question again: - Who leads? - Keep old code or start new? - Scons, what do we do with it? - Where are the requirements? - Where is the design? I can help with some points, I am in and will invest time in this project if we get things sorted out. One more time this thread is about the future of Cons not it's present. After the borring stuff I'd like to answer my own questions (some of them at least) Language: I'd like to keep perl as dev. Language, I'm fluent in perl and Python is just too boring (that is MY opinion) and there is quite a lot of construct files out there. Now the good new is that nothing stop us from having both languages (perl can call python and I'd guess the opposite works as well) even though I'd rather have a perl only solution. Money: there have been quite a lot of discussion about financing; some say they will finance other that things would happen if there is money in the path. I really dislike both of them. My energy level drop to "watch-tv-instead" level as soon as money is involved. Requirements: Generalize Cons (Make shines here), parallel cons (I mean multi machine build not single machine multiple processors) Code: I am for a complete rewrite (possibly using some of Cons and SCons code). Shorter, easier code (so even new comers can help quickly). No 6000 lines blob and certainly no user documentation included in the code. I have nothing against "generating" the final perl script with documentation included. Documentation for the strategy used in the code is a must. Get our heads out of the sand and see if there are modules that can do some of the job. Cons is quite self contained and that is good, up to the point where it is uselessly self contained. Backward compatibility: If a re-write is to be done I'd like to have the old scripts work if they do not force any structural thinking in the new design My 0.20 Sek (that's 0.02$) Nadim.. _______________________________________________ [email protected] http://mail.gnu.org/mailman/listinfo/cons-discuss Cons URL: http://www.dsmit.com/cons/