Garance is the pumpkin for the 2.8.0 release.
If you'd like to claim one of these items, grab a copy of the latest test core from
ftp://ftp.lily.org/lily/, make the changes, test 'em out, and get them back to garance (as a moo DB is fine) with notes about what you changed. (and, add a note to the item below to indicate you're working on it.)
(you should probably contact me to see about the mooDB to start from, as there have been a lot of changes from even the most recent snapshot that is available at ftp://lily.acm.rpi.edu/lily/core/ ... - Garance)
You've probably been wondering why this Wiki entry has been so quiet for the past nine or ten months. Well, even though there are only a few more "little things" left to do, I have been having a lot of trouble getting myself motivated to finish off those last details. It now seems to me that my biggest misgiving is that there are a few more "BIG CHANGES" that I really want to get done before making this release.
Right now this release incorporates a huge number of improvements over the previous official release, but it will be a major headache for any existing lily-site to upgrade to. I expect that is pretty much unavoidable, so that doesn't really bother me. What does bother me is that the next release will probably just as much of a nighmare to upgrade to as this one will be. IMO, as it stands right now this release does not do enough to make the next release any easier for people at other (non-RPI) sites. So, I want to make at least some changes which will improve on that situation before making this an official release. -- gad/Nov 28/2005
Issues that need to be resolved before that release is cut:
- I should note that I have something specific in mind to accomplish what I wrote (above) on Nov 28th. I even have a rough outline of it in a text file I have at home. It is probably a bad sign that the last three times I've connected here to write up the details, something has interrupted me for long enough that I just cancel the 'edit' here on the TWiki page. And as I type this, I suspect my UPS may be melting down . So this may very well be a fourth time. Anyway, if I ever do get the time to write my plans up, they will appear as ReorgToSupportSiteConfigs. Those plans have several specific steps, which will be listed as sub-entries under this entry... -- gad/Dec 05/2005
- We should correctly document (in
/help ) and give examples of the /review options of set, tag, prev, and next. These are useful, but I only know that they exist and how to use them because I read the source code. Also, /review prev (without any time period specified) should probably review from the beginning of the buffer to the current tag-point, if that's not too hard. And /review prev and /review next should maybe warn when you're moving the tag past the beginning (or end) of the buffer. -- gad/Aug 03/2006
- Make some effort to improve the performance of
/review when processing very large review buffers. Achorrath has a server with buffer-max set around 5,000 events. I have already added some performance improvements in a few verbs, we might want to add some more. (I'm also interested in this so we could increase the buffer-max on the main RPI server...). -- gad/Aug 03/2006
- Add back in the
ohell game which Whammy had implemented for lily almost 12 years ago. Maker dug up an old core which included the game, and has done most of the necessary work. Just need to do some more testing. -- gad/Aug 03/2006
- Need to think about the issue where making the MOO function call
suspend(0) means that commands can be executed out-of-order, especially since we're calling that function in a lot more places nowadays (I should explain this issue in greater detail). Doing something to address this issue will probably have to wait until some later release._ -- gad/Aug 03/2006
- There were some odd bugs noticed in LambdaMOO when compiling it on newer OS's. I believe those are now fixed, so the details have been moved to the ReadyForRelease280 page. -- gad/Jun 05/2006
- IF we need a new version of the MOO program (the actual program in C, which implements the MOO programming environment), I intend to pick a new name for that MOO. I'm tired of people having trouble with a lilycoreDB only because they picked up a snapshot of the official LambdaMOO project, instead of a version which has the changes lily needs. This means we now have a to-do item of: NameThatMOO. -- gad/Dec 09/2005
- Remove some of the old objects/verbs which are no longer used, and which just confuse people (like me...) who are trying to figure out what the present code is doing.
- Straighten out and centralize the checking for invalid characters in various names (discussions, groups, users, memos, aliases, etc).
- Right now it's scattered around a few objects, with the implementations slightly different in each. The implementations had actually gotten way out of sync, but I have at least gotten them somewhat more consistent.
- Also, there is PR #29 on how memo-names aren't checked at all, and that there are some special characters that can be added in memo names which will then screw up the %import_file command.
- There's another PR (#506) that notes that the /new/ web form allows users to request names which are not valid. Probably an issue for both user-names, and the login id they pick.
- And PR #178 notes a problem with characters allowed in /alias.
- The new /alias command now limits the characters allowed in new alias names. -gad/Dec 26/2003
- Decide on and implement a nicer syntax for '/rename -disc <oldname> <newname>'
- Perhaps '/drename <oldname> <newname>' - gad
- Perhaps just '/rename -<oldname> <newname>', where the '-' prefix is required on the old name (and perhaps on both names) to distinguish a discussion rename from renaming to a multi-word username - Maker
- Note that the problem here is how /rename currently handles user-names which have blanks in them. You can '/rename My New Name', and the command parses all of that as a single username. The user is not required to use double-quotes or underscores, as they are in many other lily commands. My guess is that we should just change /rename so it does require underscores or double-quotes the same as other commands. - gad
- PR #452 is another vote for getting /rename to parse names the same as other commands... - gad
- I expect that the $TRANSFER code would need a lot of work, assuming someone plans to use it. I have no plans to work on $TRANSFER myself, but if someone forwards changes to me I'll try to include them.
- Given LilyInCvs, I hope to make $transfer obsolete. -Coke
- Well, certainly that's the preferred goal. But that's not going to happen in time for 2.8.0 release, is it? - Garance
- My point was "I wouldn't bother fixing it for 2.8.0". Unless there is another core out there that is clamoring for it. Obviously for RPI, it JDM. -Coke
- [etc]
- There are other items I want to fix up before release, but I don't have the list sitting in front of me at the moment. -gad
- Some of these items will probably slip to a later release (NeededForRelease281), if I run out of time or energy, but I wanted to at least write them down... -gad
The remaining entries in the original "must do" list have been moved to a
ReadyForRelease280 entry, simply to make this web page smaller and less-intimidating. -- gad/Nov 28/2005
-- initial version of this list by
CoKe - 04 Dec 2003
-- list updated frequently by
GaranceDrosehn (aka -gad)
to top