Mailing List Archive

New weekend, new sprint to fix 1.17 blockers
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_resolved=1

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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
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.3F

That's what I get for writing e-mails at 5am ;-)

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
Hello,

I am out of the office traveling for business. I am checking my email, however my response may be delayed. I will be in Los Angeles CA for the ASCII success summit held on the 23rd and 24th of February and in Seattle, WA for MVP Nation held on 3rd and 4th of March. I would like to meet with our partners, so if you are traveling to these events or just in the area and would like to get together, please send me an email so we can make arrangements.

If your need is more immediate and you would like to speak with someone at Datto HQ, please use the following:

For technical support, please contact the support team at 877-455-6015 or
support@dattobackup.com

For sales assistance, please contact Angelo Zucaro at 203.529.4985 or
azucaro@dattobackup.com


Regards,
-Austin W. McChord
Datto Inc.
Phone: 203-665-6423
Fax: 203-665-0391
Email: amcchord@dattobackup.com
Web: www.dattobackup.com






_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
Hello,

I am out of the office traveling for business. I am checking my email, however my response may be delayed. I will be in Los Angeles CA for the ASCII success summit held on the 23rd and 24th of February and in Seattle, WA for MVP Nation held on 3rd and 4th of March. I would like to meet with our partners, so if you are traveling to these events or just in the area and would like to get together, please send me an email so we can make arrangements.

If your need is more immediate and you would like to speak with someone at Datto HQ, please use the following:

For technical support, please contact the support team at 877-455-6015 or
support@dattobackup.com

For sales assistance, please contact Angelo Zucaro at 203.529.4985 or
azucaro@dattobackup.com


Regards,
-Austin W. McChord
Datto Inc.
Phone: 203-665-6423
Fax: 203-665-0391
Email: amcchord@dattobackup.com
Web: www.dattobackup.com






_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: New weekend, new sprint to fix 1.17 blockers [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l