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 <mhershber...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
