Brion Vibber wrote:
On Apr 22, 2004, at 07:43, Ashar Voultoiz wrote:
I am wondering if all of those are ready to make
a 1.3 "stable"
release or if there is still some work to be done.
If everything is fine, what are we waiting for to release 1.3.0 ?
If not wich part should I look at and help finish ? ;)
Fix bugs, bugs, bugs, bugs, bugs, bugs, bugs, and bugs.
Since when have we ever worried about that? ;)
Documentation updates.
Additional touches to in-place install. Removal of the old, dangerous
command-line install. Getting maintenance scripts usable (but safe)
in the in-place environment.
I've already checked in a method for checking if a command-line script
really is being run from the command line, and exiting with an error
message if it isn't. IMHO the best thing to do with the command line
scripts would be to convert them to scripts runnable from the ordinary
web interface, with password-based (possibly SSL) authentication.
Make sure upgrading from previous versions is a clean,
easy process.
I'm worried about the help namespace -- a number of messages have been
changed to point to the Help namespace instead of the Wikipedia
namespace. This will break links, and may go unnoticed on smaller
installations.
Is there any way to execute scripts for schema changes from the web
installer? It would be nice to see convertLinks.php work from the web
interface. Note that convertLinks.php will require downtime, perhaps an
hour or so depending on the speed of the speed of the database server.
moveCustomMessages.php doesn't require downtime, although to safely
avoid downtime requires some human know-how. Again, it's only runnable
from the command line.
In the long term (post 1.3) it might be nice to have a general way to
deal with schema changes, involving automatic detection of missing
fields and tables, based on a single schema specification. The
specification could then be used for both installing and updating.
Finish cleaning up Preferences.
MonoBook is still missing the occasional bit (for instance, there is
no printable-version or RSS link.)
Update all the language files with new stuff.
Gabriel has suggested switching our language management stuff to a
utility such as GNU gettext, to make this task easier.
http://www.gnu.org/software/gettext/gettext.html
Needless to say, it would require a lot of work to maintain the current
ability to configure via the web interface. Definitely a job for a later
release.
There's a few bits and pieces I'd like to get done before 1.3, but I'm
not sure if I'll have time. For example, the template parameter syntax
chokes on something like {{thing|x=[[Foo|Bar]]}}. I think the solution
is to move the brace handling code to the tokenizer section.
The other thing that I want to do is to work on profiling and
optimisation. The main entry point of the parser is called a lot more
often than it used to be, I think there might be some need for moving
various kinds of initialisation to the constructor, or to static variables.
We're getting pretty tight for CPU time at the moment, it seems to be
causing minor slowdowns in peak times. It might be wise to fix up Snok's
parser cache and enable it on the live site.
-- Tim Starling