(Erik Moeller erik_moeller@gmx.de): Lee,
I don't think we should completely redesign things from scratch. See http://www.joelonsoftware.com/articles/fog0000000069.html about rewriting in general.
I'm well aware of refactoring; that's the main reason I want the test suite first. But this is a case a little different from what Joel is describing: we're starting with a complete feature set and (at least initially) not making any changes at all to that. That in a sense makes it a refactor job even if we do replace the actual code. If we decide that Apache/PHP/MySQL is the tool of choice, we will of course not throw away code at all but just refactor all the way.
- PHP is not and has never been a problem. Virtually all our
performance problems have been related to specific SQL queries (either a very high number of them, or complex ones). I do not see any reason at all to stop using PHP.
I can believe that.
- Getting MySQL to perform properly largly depends on using
indexes the right way. This means providing composite indexes where needed. In the case of timestamps, we had to add a reverse timestamp column for it to be index-sorted fast, but while this is a hack, it is a needed hack until MySQL4...
I'm still concerned, though, that even if we optimize all the indexing, we'll never achievea speedup of more than 2-3x. I don't know if that will be enough in the long run. After the test suite is done, I can do some head-to-head testing of things like indexes and MySQL 4.X.
I think our priorities should be this:
- Get some of the other language Wikipedias up that people are
waiting for. If there are motivated users who want to start a Wikipedia in their language, we should not let them wait.
I agree that this should be a priority for the project. I'm not as convinced that it's the best use of /my/ time, and since my absence I'm more committed to ensuring that I don't burn out again by spending my own time on things I'm not best suited to. I think it should be up to motivated foreign users to migrate their own wiki. The presence of someone skilled enough to do that should be evidence of the level of desire.
- Fix known bugs and try to improve the speed in case of
remaining bottlenecks.
Agreed. This can also be done in parallel with new development if needed, and if the speedups are dramatic enough, perhaps it will show that new development isn't needed after all.
- Implement suggested improvements.
- Improve search + redirect handling
- Finish Magnus' interlanguage links redesign
- Fix Recent changes layout
That's one of my concerns too: I spent about three weeks trying to do this, but it just wasn't possible to get the features I wanted with the current architecture and acceptable performance.
- Redesign image pages - Redesign talk pages - Improved edit conflict handling (CVS style merge)
Hmm. I'm not sure about that one.
- Backends (SVG, Lilypond), syntax improvements etc.Aside from this, an entirely new project is the dedicated Wikipedia client, for offline reading and, hopefully, ultimately for editing as well. Magnus has started working on this.
That's great. That's probably better suited to his talents.
What I understand to be "Phase IV" is, then, a point where we have finished all the important fixes and improvements and then decide to move on to "nice to have" stuff. Among this is the much requested multilanguage portal for Wikipedia, with a multilanguage search, RC etc., and possibly merging the databases of the different Wikipedias (at least the user data). I do think the current software can and should be used as a basis for the next phase(s).
Cross-language stuff is a big issue too. I confess that I ignored that issue 100% in the present design. If we can add those features without looking like a hack, I'm all for it, but I suspect a new architecture will help there more than anywhere.