MediaWiki 1.2.0rc1 is now available for download at: https://sourceforge.net/project/showfiles.php?group_id=34373
This is a release candidate, and may contain a few rough edges still. Those feeling adventurous, please try it out -- on a safe server after backing up all your data -- and please report any exciting new problems. If we don't hear about your problems, they'll never get fixed!
A few notes: * Things should again work out of the box with MySQL 3.x (though 4.x is preferred). * We are now compatible with short_open_tag = Off * wiki.phtml and redirect.phtml have now become index.php and redirect.php to improve compatibility. The old names are still available for compatibility, so you don't have to change your configuration for existing installs. If you're mixing other stuff in with the wiki's install directory, please be sure this doesn't conflict with other existing files! * Installation now prompts you to ask if you want to create a sysop or developer account and lets you pick the name and password instead of using the AdminSettings.php defaults. * A new page, Special:Version lists the MediaWiki, PHP, and MySQL version numbers. Please don't forget to note these when reporting bugs! We tend to track current production releases of PHP and MySQL, and sometimes things break on older or experimental versions of these that we don't always see.
Database messages are now on by default, you can turn this off if the performance hit is too great. We hope to improve the speed of this soon.
A couple things we don't have in yet: * We don't yet have an installer that's friendly to those without shell access, sorry. Hopefully we'll have something for 1.2.0 final. * We still require register_globals = On. * No PHP5 compatibility. I know there are a few keyword conflicts which should be easy to fix, but we haven't tested this yet.
See the file RELEASE-NOTES for a bit on the new features and bug fixes.
You can report problems at SourceForge at: http://sourceforge.net/tracker/?group_id=34373&atid=411192
-- brion vibber (brion @ pobox.com)
In CVS, the 1.2.0 stuff has been put onto the REL1_2 branch. You may once again put experimental fun stuff into the head branch without fear... :)
-- brion vibber (brion @ pobox.com)
On Sat, Feb 28, 2004 at 01:11:04AM -0800, Brion Vibber wrote:
MediaWiki 1.2.0rc1 is now available for download at: https://sourceforge.net/project/showfiles.php?group_id=34373
I would like to upgrade from 1.1.0 stable. What I have to do? Thank you.
Regards. Alberto.
On Feb 28, 2004, at 02:10, M.Alberto wrote:
On Sat, Feb 28, 2004 at 01:11:04AM -0800, Brion Vibber wrote:
MediaWiki 1.2.0rc1 is now available for download at: https://sourceforge.net/project/showfiles.php?group_id=34373
I would like to upgrade from 1.1.0 stable. What I have to do? Thank you.
1) backup everything! 2) Download and uncompress the tarball, above. 3) Copy in your AdminSettings.php and LocalSettings.php from 1.1.0 4) run 'php update.php'. This will make the necessary tweaks to the database and install the updated PHP scripts.
If you're doing a manual install because the install script doesn't work for you, you can upgrade manually: 1) backup everything! 2) Load patch-rc-newindex.sql and patch-ipb_expiry into your database (via the mysql command-line client, or phpmyadmin, or whatever). They're in the tarball under maintenance/archives. 3) Copy *.phtml index.php redirect.php LocalSettings.php includes/*.php languages/*.php into the destination directory to update the scripts. 4) Copy stylesheets/*.css stylesheets/*.js into the style subdirectory 5) Copy images/*.png into the upload subdirectory 6) Hope things work... :)
You might also need to run rebuildMessages.php (in the maintenance directory) to get the MediaWiki interface messages up to date.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
and please report any exciting new problems. If we don't hear about your problems, they'll never get fixed!
Have you fixed the problem with Special:Whatlinkshere?
Example: The following Whatlinkshere page suggests that there is a double-redirect where there isn't actually one: http://en.wikipedia.org/w/wiki.phtml?title=Special:Whatlinkshere&target=... Now, I have *not* tried to edit the wrongly-displaying redirect to see if this would fix the problem, because if it does, then this evidence would be gone and I would have to perform more tests to see if the bug was actually fixed.
You can report problems at SourceForge at: http://sourceforge.net/tracker/?group_id=34373&atid=411192
Honestly, if you want for people to report and manage bugs in an efficient manner (or even if you just want me to get involved :) ), you seriously need to trash this SourceForge Tracker and use BugZilla.
Timwi
"T" == Timwi timwi@gmx.net writes:
T> Honestly, if you want for people to report and manage bugs in T> an efficient manner (or even if you just want me to get T> involved :) ), you seriously need to trash this SourceForge T> Tracker and use BugZilla.
It'd actually be cooler to use meta.w.o to track bugs.
~ESP
Evan Prodromou wrote:
"T" == Timwi timwi@gmx.net writes:
T> Honestly, if you want for people to report and manage bugs in T> an efficient manner (or even if you just want me to get T> involved :) ), you seriously need to trash this SourceForge T> Tracker and use BugZilla.It'd actually be cooler to use meta.w.o to track bugs.
Possibly; it would be more wiki-like. However, BugZilla has a vast amount of organisatorial features, most notably for searching, and resolving bugs esily. It is also very well-known (and well-appreciated) in the open-source community.
Timwi
"T" == Timwi timwi@gmx.net writes:
T> Honestly, if you want for people to report and manage bugs in T> an efficient manner (or even if you just want me to get T> involved :) ), you seriously need to trash this SourceForge T> Tracker and use BugZilla.
I agree the bug tracker on sourceforge sucks.
Bugzilla unfortunately is also horribly intimidating to use. If *I* find it intimidating, think what joe random "I'm having a problem, I just want to see it fixed" is going to think. My eyes glaze over just tyring to do a search!
(Of course, it took me two years to notice that one *can* search in the sourceforge bug tracker. It really really is badly designed.)
On Feb 28, 2004, at 08:09, Evan Prodromou wrote:
It'd actually be cooler to use meta.w.o to track bugs.
Tracking bugs on wiki pages is terribly difficult too, unfortunately; that's why we started using the tracker. Reports get left, then we ask for more information, and the original poster never comes back to check. Duplicates aren't managed. The list gets very long and things disappear without being kept after. Nobody gets notification of changes in state.
Perhaps if we put more work into organizing bug reports on the wiki it could be managed (one page per bug, use your watchlists, be really anal about keeping order in the list page), but historically this has not done well.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Bugzilla unfortunately is also horribly intimidating to use.
[snip]
Take a look at Scarab, http://scarab.tigris.org.
Cheers, Ivan
Brion Vibber wrote:
Bugzilla unfortunately is also horribly intimidating to use. If *I* find it intimidating, think what joe random "I'm having a problem, I just want to see it fixed" is going to think.
I fully agree that BugZilla has a somewhat steep learning curve *for non-developers*. However, this has a pleasant side-effect...
Namely: Do we really want Joe Random User to submit bugreports? Just yesterday there were a few (well, at least one) completely bogus bugreport(s) on the SourceForge tracker, and it led me to unsubscribe from the newsgroup that mirrors it.
I really think it would make a *LOT* more sense if we had a central page on Wikipedia (or Meta-Wikimedia) where Joe Random User can submit a bugreport, and whoever likes to volunteer should transfer them to BugZilla if they think it's a genuine bug. I am confident that a large number of (current and future) developers [will] already know BugZilla from elsewhere, and even if they don't, learning it for Wikimedia is useful because then they'll know it for other projects.
Those are my thoughts. Timwi
"BV" == Brion Vibber brion@pobox.com writes:
Me> It'd actually be cooler to use meta.w.o to track bugs.
BV> Tracking bugs on wiki pages is terribly difficult too, BV> unfortunately; that's why we started using the BV> tracker. Reports get left, then we ask for more information, BV> and the original poster never comes back to check.
I wonder if the advantages we get out of wiki for producing other content would come into play here. A report gets left, and then somebody else cleans up the report into a preferred format. Someone else gives more specific information, and someone else assigns the bug to a person ("Assigned to: [[User:Evan]]").
Bugs that get reported and not followed up on fall to the bottom of the stack, or go on [[m:Unverified bug reports]] or something.
The thing is that we deal with most problems with Wikipedia (and the other wikis) on-wiki, but we try to separate one part of it -- software problems -- elsewhere. And, y'know, the place we chose to do that is far off-site, and it's slow and has a crummy interface.
~ESP
On Feb 29, 2004, at 11:26, Evan Prodromou wrote:
"BV" == Brion Vibber brion@pobox.com writes:
Me> It'd actually be cooler to use meta.w.o to track bugs. BV> Tracking bugs on wiki pages is terribly difficult too, BV> unfortunately; that's why we started using the BV> tracker. Reports get left, then we ask for more information, BV> and the original poster never comes back to check.I wonder if the advantages we get out of wiki for producing other content would come into play here. A report gets left, and then somebody else cleans up the report into a preferred format. Someone else gives more specific information, and someone else assigns the bug to a person ("Assigned to: [[User:Evan]]").
Like I said, we *could* but in practice *that did not happen in 2002*. If someone would like to commit to being Keeper of the WikiBugs and herd the necessary cats, then I'm all in favor of giving it a try.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
On Feb 29, 2004, at 11:26, Evan Prodromou wrote:
I wonder if the advantages we get out of wiki for producing other content would come into play here. A report gets left, and then somebody else cleans up the report into a preferred format. Someone else gives more specific information, and someone else assigns the bug to a person ("Assigned to: [[User:Evan]]").
Like I said, we *could* but in practice *that did not happen in 2002*. If someone would like to commit to being Keeper of the WikiBugs and herd the necessary cats, then I'm all in favor of giving it a try.
I would like to commit to being Keeper Of A Bugreport Page On Which General User Can Submit Bugreports That Will Then Be Moved To The Almighty Bugzilla. :-)
Timwi
Brion Vibber wrote:
If someone would like to commit to being Keeper of the WikiBugs and herd the necessary cats, then I'm all in favor of giving it a try.
I might be willing to take this on; I'd just like a sound understanding of what cats you're specifically referring to herding. Other than the keeptrack-assign-verify-close process, what else do you feel would need to be done?
Cheers, Ivan
Ivan Krstic wrote:
Brion Vibber wrote:
If someone would like to commit to being Keeper of the WikiBugs and herd the necessary cats, then I'm all in favor of giving it a try.
I might be willing to take this on; I'd just like a sound understanding of what cats you're specifically referring to herding. Other than the keeptrack-assign-verify-close process, what else do you feel would need to be done?
Some of the almost essential features of BugZilla include: * Severity and/or priority * Keywords (every BugZilla installation has a pre-defined set of them) * Status (unconfirmed, new, assigned, resolved, verified, closed) * Resolution (if the status is "resolved", was it "fixed", "invalid", "duplicate" (if so, of what other bug), "wontfix", "worksforme", etc.) * SEARCHING! Searching for combinations of all of these criteria, plus when a bug was last changed, when it was opened, by who, etc.etc.
Some of the not-so-essential-but-highly-useful features: * CC lists. (Getting e-mailed with every change to a bug.) * Even more SEARCHING! Complex queries for highly specific purposes.
I can't think of more for now, but there's probably more :-)
I can see all of these implementable in a Wiki (with e-mail CC lists replaced by watchlists), EXCEPT FOR SEARCHING. Unfortunately, searching is the most important of all. This is why I don't think it's feasible to use a Wiki for this.
Of course, we could also have some sort of hybrid system. Discuss bugs on the Wiki, but keep track of their status on BugZilla.
Just a suggestion, Timwi
On Feb 28, 2004, at 07:49, Timwi wrote:
Brion Vibber wrote:
and please report any exciting new problems. If we don't hear about your problems, they'll never get fixed!
Have you fixed the problem with Special:Whatlinkshere?
There's nothing wrong with Special:Whatlinkshere. There is corruption in the link tables on Wikipedia, which is visible in Special:Whatlinkshere.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
On Feb 28, 2004, at 07:49, Timwi wrote:
Brion Vibber wrote:
and please report any exciting new problems. If we don't hear about your problems, they'll never get fixed!
Have you fixed the problem with Special:Whatlinkshere?
There's nothing wrong with Special:Whatlinkshere. There is corruption in the link tables on Wikipedia, which is visible in Special:Whatlinkshere.
That didn't answer the question on whether it has been fixed (i.e. whether re-submitting the pages would update the link tables correctly).
On Feb 28, 2004, at 19:57, Timwi wrote:
Brion Vibber wrote:
On Feb 28, 2004, at 07:49, Timwi wrote:
Brion Vibber wrote:
and please report any exciting new problems. If we don't hear about your problems, they'll never get fixed!
Have you fixed the problem with Special:Whatlinkshere?
There's nothing wrong with Special:Whatlinkshere. There is corruption in the link tables on Wikipedia, which is visible in Special:Whatlinkshere.
That didn't answer the question on whether it has been fixed (i.e. whether re-submitting the pages would update the link tables correctly).
Please try it and report back.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
On Feb 28, 2004, at 19:57, Timwi wrote:
That didn't answer the question on whether it has been fixed (i.e. whether re-submitting the pages would update the link tables correctly).
Please try it and report back.
OK, I've tried it. The bug is *not* fixed.
http://en.wikipedia.org/w/wiki.phtml?title=Special:Whatlinkshere&target=... still indicates a double-redirect which doesn't exist.
It also lists many pages several times. Editing those pages doesn't succeed in updating the links table correctly.
Greetings, Timwi
On Feb 28, 2004, at 01:11, Brion Vibber wrote:
- No PHP5 compatibility. I know there are a few keyword conflicts
which should be easy to fix, but we haven't tested this yet.
Actually, it seems that these may have been fixed already. I've done a quick test with PHP 5.0.0b4 and haven't run into any problems yet. I'd appreciate a confirmation on this from anybody who's using PHP 5 more regularly or notices that a particular operation does fail.
-- brion vibber (brion @ pobox.com)
Brion-
On Feb 28, 2004, at 01:11, Brion Vibber wrote:
- No PHP5 compatibility. I know there are a few keyword conflicts
which should be easy to fix, but we haven't tested this yet.
Actually, it seems that these may have been fixed already. I've done a quick test with PHP 5.0.0b4 and haven't run into any problems yet. I'd appreciate a confirmation on this from anybody who's using PHP 5 more regularly or notices that a particular operation does fail.
I briefly tested it with b2 and fixed obvious keyword conflicts. There might still be a lingering incompatibility here or there, though.
Regards,
Erik
wikitech-l@lists.wikimedia.org