Since several people gave me some very positive feedback about last weekend's sprint to fix the tarball blockers for 1.17, I'm going to have a new sprint to fix the 1.17 blockers. Before we get started, though, let me give some recognition to the people who have fixed bugs this past week:
27440 Special:Types non-functional on 1.17 Jeroen De Dauw (SMW bug that probably shouldn't have been a tarball blocker, but, hey!, thanks Jeroen!) 27506 <gallery> is printed in 1 file per row Krinkle 27607 Special:NewPages only showing last 24 hours since 1.17 Derk-Jan Hartman closed it WORKSFORME
There were also two bugs that, after investigation, are no longer tarball blockers:
27474 [[#_foo|bar]] renders with href="#foo" , breaking Cite anchors configuration issue 27571 GRAMMAR rules from $wgGrammarForms don't work with fallback-language Niklas Laxström told me he couldn't reproduce this one or track it down
And now, the still-outstanding blocker bugs. A couple of bugs have been added, but I think that overall we're making good progress. First, the bugs related to the new installer that Tim mentioned last week. Since the installer will be the first exposure many people have to 1.17 and the code is all new, I think these deserve special attention.
12070 After Installation MySQL was blocked 26481 New installer doesn't fill in the $*Key values some times 26612 Regression: Postgres cannot install 26937 Deleted file path not visible when going back to page=Options 27579 Chrome saves config as LocalSettings.php.php
Chad made some real progress on the Postgres installer (26612) and I said that I would take care of the remaining issue in, but I haven't had a chance yet. Chad and Platonides have been working on 12070. Meanwhile, 26481, 26937, and 27579 look pretty easy. I expect we could have all this taken care of this weekend.
If the UI is your thing but the installer bugs don't grab you, have a look at these:
27023 once dom ready mediawiki.loader.using issues callback before modules are ready 27490 RTL ui in LTR wiki is LTR aligned 27540 width of <gallery> always 100% 27566 New wikilink window grows in width each time when opened in Chrome 27577 Gallery perrow width is overestimated 27679 Ugly encoding in red file links containing an ampersand 27693 Doing double bar in image link inside table changed behaviour
Finally, a couple more bugs if you none of the above whets your appetite:
27403 Disabled preferences are taken into account anyway 27473 Apostrophe in linktrail breaks bolded links
I haven't included one blocker in the list because I think P.Copp's javascript minimizer fixes it. However, his contribution hasn't been installed yet, so there may still be room to try your hand:
27528 JS minification still outputs incorrect javascript for some input
If you're going to try your hand at any of these, I suggest you post a comment to wikitech-l so we have an idea of what you're doing.
Note that if any of these don't excite you, you should check out #27339 blockers: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=27339&hide_reso...
Some of these require shell access, but some are bugs with MediaWiki extensions used on Wikimedia.
As always, if you need help figuring something out or tracking down one of these bugs, ask on #mediawiki on freenode.
Happy hacking!
Mark.
I'd also like to thank you for these e-mails. They're a nice summary, and way easier reading than BZ dependency lists. I'm focusing on the installer right now, replies inline...
On Fri, Feb 25, 2011 at 8:21 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
And now, the still-outstanding blocker bugs. A couple of bugs have been added, but I think that overall we're making good progress. First, the bugs related to the new installer that Tim mentioned last week. Since the installer will be the first exposure many people have to 1.17 and the code is all new, I think these deserve special attention.
Tim's right, we *cannot* release 1.17 without a functional installer--and it's far too late to roll back to the old installer. That being said, I think "major parts missing" is a bit of an overstatement (barring the issues below). Of course, there's still a handful of general installer bugs[0] other than the ones you've mentioned. Fixes for these can probably be snuck into 1.17 if someone is feeling so bold and the merge is clean.
12070 After Installation MySQL was blocked
Like you said, I'm on this one. There's a patch attached which just needs a little more cleanup, but solves the underlying issue.
26481 New installer doesn't fill in the $*Key values some times
I *really really* don't like the "regenerate LocalSettings" option for post-upgrade. It takes you back through all the normal setup questions including ones you probably won't change (eg: site name). It also doesn't load your current settings, which means you could easily make a new LocalSettings that differs from your current install. Not to mention, all of the text on those pages is phrased for an install, not an upgrade which is mildly confusing. In the short term, I'd rather just disable the feature entirely. If we did, it would solve this by making it go away. Really, I'm not sure why I put the secret key generation as an install step...probably just so I could bounce a Status back up if we can't use /dev/urandom. Some refactoring would fix the mentioned bug, but I think there's a bigger issue here I've outlined that merits discussion.
26612 Regression: Postgres cannot install
Whee postgres :) More below... Btw, Tim's comments on Postgres are on this bug[1].
26937 Deleted file path not visible when going back to page=Options
There is an easy fix for this one. As pointed out on mediawiki.org[2], configuring the deleted directory is a "power option" that most users don't need to see. "$wgUploadPath/deleted" works for most people. If no one has any arguments for keeping it in, it would be trivial to just remove it entirely and fall back to defaults. Generally speaking, we seem to have a few errors where the entered values are not saved....$wgSiteName is another, but for completely unrelated reasons[3].
27579 Chrome saves config as LocalSettings.php.php
I haven't looked at this at all. Seems fairly trivial from the summary though.
Chad made some real progress on the Postgres installer (26612) and I said that I would take care of the remaining issue in, but I haven't had a chance yet.
Let me just start by saying I hate our Postgres support :) We've made a lot of progress in Postgres in the past few weeks, but I'm not a Postgres user at all, so testing some of this stuff is new territory for me. I'd like to get some other Postgres users (OverlordQ, Greg M.?) to try things out. In my current trunk, I can get installs to work, but it starts to have issues once you start changing defaults. Please keep in mind that we dropped the back-compat stuff for tsearch2, so the minimum supported version is 8.3 (I've been testing using 8.4).
I'm also adding bug 26481[4] as a blocker to release ($wgDBmwschema is ignored on installation, always falls back to 'mediawiki'). This is broken behavior, and has existed since the old installer. It's completely wrong that you should specify a schema and then it fall back to a default unconditionally (which results in a broken install and requires changing $wgDBmwschema). I haven't poked *why* this is the case yet.
I'm also getting a really weird error that Mark has been unable to replicate yet and I'm rather baffled by it. When creating tables, the installer is creating all the tables in both the public AND mediawiki schemas. Now, post install it actually uses the correct schema, but I'm not sure why it's duplicating the tables in the public schema. I'd like to fix this if we can, since it's making the install much slower (double table creation!). If someone could track this down, that'd be great (it's not a show-stopper, just annoying...)
As a general note, I'd like it if developers took the time over the next couple of days to at least run the installer if they haven't already. More eyes can't hurt. The UI could use another pass from one of our ninjas (Brandon? Trevor?) to find/fix some of the more glaring issues that are there...we can make it all pretty and ajaxy in 1.18 :) There's at least two issues in BZ know of off the top of my head[5],[6].
If someone is looking to play with the installer and needs something to look at, feel free to ping me on IRC when I'm around, I'm sure I can find something :)
Have a great weekend, and happy hacking,
-Chad
[0] http://is.gd/svqCXU [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26612#c6 [2] http://www.mediawiki.org/wiki/New-installer_issues#Non-critical (below the sitename section) [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=22579 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=26689 [6] https://bugzilla.wikimedia.org/show_bug.cgi?id=26691
On Sat, Feb 26, 2011 at 5:05 AM, Chad innocentkiller@gmail.com wrote:
Generally speaking, we seem to have a few errors where the entered values are not saved....$wgSiteName is another, but for completely unrelated reasons[3].
Ariel pointed out I missed a link to [3] here. The link is: http://www.mediawiki.org/wiki/New-installer_issues#.24wgSitename_forgotten.3...
That's what I get for writing e-mails at 5am ;-)
-Chad
On Sat, Feb 26, 2011 at 5:05 AM, Chad innocentkiller@gmail.com wrote:
26937 Deleted file path not visible when going back to page=Options
There is an easy fix for this one. As pointed out on mediawiki.org[2], configuring the deleted directory is a "power option" that most users don't need to see. "$wgUploadPath/deleted" works for most people. If no one has any arguments for keeping it in, it would be trivial to just remove it entirely and fall back to defaults. Generally speaking, we seem to have a few errors where the entered values are not saved....$wgSiteName is another, but for completely unrelated reasons[3].
That bug is unrelated to my ramblings about $wgDeletedDirectory. Also unrelated to the $wgSiteName problem. Sorry for any confusion.
-Chad
On Fri, Feb 25, 2011 at 8:21 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
There were also two bugs that, after investigation, are no longer tarball blockers:
27474 [[#_foo|bar]] renders with href="#foo" , breaking Cite anchors configuration issue
$wgHtmlExperimentalIds should probably be set to false by default if this isn't fixed soon. The issue occurs with default config -- it's only a config issue in that you can avoid it by changing config options.
2011/2/26 Mark A. Hershberger mhershberger@wikimedia.org:
I haven't included one blocker in the list because I think P.Copp's javascript minimizer fixes it. However, his contribution hasn't been installed yet, so there may still be room to try your hand:
27528 JS minification still outputs incorrect javascript for some input
I will take care of this one on Monday or Tuesday.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org