Luke Gorrie luke@bluetail.com writes:
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Today we received bugreports like "CLISP hangs on startup", "SBCL dies with SIGBUS", "can't set FPU modes". Desn't seem like SLIME is ready for release and making a tarball will not help us getting there.
I agree. Our current rock&roll development style makes this all pretty easy to handle: "Foo is broken [here's a patch]." "Fixed in CVS now." Much more fun than "That'll be fixed in the next release."
The important thing is to make the best Emacs programming mode known to man in the fastest and most enjoyable way. The rest is secondary.
But thanks Brian for the vote of confidence in the current maturity! However, I think having cautious people avoid SLIME initially is a much lesser evil than having them download it thinking it's more mature than it really is and then curse and swear at it.
BTW, SLIME is the most fun project I've been involved in and I attribute much of this to everyone using the same CVS code. With 31 hackers listed in the ChangeLog we must be doing something right :-)
I agree with Brian that SLIME is mature enough for a release. However, I also agree with Luke that it's more fun working with the CVS copy.
The reasons that most people want a release are:
1. Some people don't like downloading out of CVS and prefer a tarball. 2. A release provides a "fixed" snapshot that you can be pretty sure works (more or less) 3. A release says to the world "We're ready for users now"
I don't know if these reasons really apply to SLIME.
For #1, as Helmut has mentioned, it is possible to download a tarball of the current CVS SLIME from: http://common-lisp.net/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=1&cvs...
This effectively negates #1. It might be worthwhile to mention the tarball in the docs and/or CLiki so that CVS-adverse users aren't scared away.
Reason #2 isn't really that important either, since the turn-around on bugs is so quick :-). For the super-wary, the FAIRLY-STABLE download provides an alternative. Is a tarball of the FAIRLY-STABLE code available also?
Reason #3 is a subjective consideration. I know that I held off trying SLIME for a long time because I thought it was still a work-in-progress and not ready for production use. However, there are a lot of people recommending SLIME now and I would say that it has the highest mindshare of the Emacs CL modes. You guys just have to learn to bite your tongues and stop saying it isn't mature enough yet ;-)
The downside to producing a release is that you encourage people to take the "stable" release as opposed to the "flaky" CVS version. This divides users and means that there are fewer eyes checking the latest code. When you have a stable, slow-changing product, this is ok. However, since there is so much active (and enthusiastic) development on SLIME, I'd say there isn't a lot of benefit in producing a "Release" yet.
- Bill
Bill_Clementson@peoplesoft.com writes:
For #1, as Helmut has mentioned, it is possible to download a tarball of the current CVS SLIME from: http://common-lisp.net/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=1&cvs...
This effectively negates #1. It might be worthwhile to mention the tarball in the docs and/or CLiki so that CVS-adverse users aren't scared away.
Some of us aren't cvs adverse, just cvs disabled when we're hidden behind firewalls at work.
cheers, Bruce
Okay!
So you guys convinced me that we should make more of an effort to explain SLIME to people, since currently it's like "the world's worst kept secret." Based on Bill's thoughts I think we can make Brian somewhat happy without actually making release tarballs :-)
To this end I have done two drastic things: made a new webpage (with HTML-hacking help from #lisp) and posted an up-to-date description of SLIME to comp.lang.lisp. I have represented us as being "at version 0.13" (i.e. FAIRLY-STABLE is at the SLIME-0-13 tag), which I hope helps explain our current state in reasonably meaningful version-number terms.
Re: making a real release, I think that when we first discussed this the main things we needed were (in my mind):
Stable code (no awful bugs that force an upgrade within a few months) Clean code (our backend interface was a mess for a long time) Documentation Proper web page
I think we're now substantially closer to having releasable code, and we pretty much have a proper manual and web page. So although we haven't been planning how to make a release, I do think we've been moving steadily towards a release-worthy state all the same.
Cheers, Luke