Hi,
It seems as though somebody's recently added a new product
to "Wikimedia" in Bugzilla for AcaWiki. I'm just curious what
AcaWiki is.
Also as a minor note to my fellow BZ admins: when you add a
new product, it's good to give it a default assignee so people
know who to prod :)
-Chad
It doesn't seem clear to the user just what changed on many lines of
http://en.wikipedia.org/w/index.php?title=Allen_Swift&action=historysubmit&…
E.g.,
|-+----------------------------------------------------------+-+----------------------------------------------------------|
|-|| ALTERNATIVE NAMES = |+|| ALTERNATIVE NAMES = |
|-+----------------------------------------------------------+-+----------------------------------------------------------|
|-|| SHORT DESCRIPTION = |+|| SHORT DESCRIPTION = |
|-+----------------------------------------------------------+-+----------------------------------------------------------|
Maybe it is removing or adding invisible characters or something.
True I could use action=raw to see what was really in there, but to the
average user it looks like one big head scratcher.
Hi all,
I'm wondering what the status for 1.17 is. How far are we from RC? Is
there any more review left?
Related to this, as our review burden for 1.17 lessens, we should
start to think about 1.18: re-recruit reviewers again, start thinking
about when to branch 1.18, etc. Are there any plans related to that?
Bryan
This summary of the past Monday's bug triage is a little late in
coming. For those who want to see the notes from the Triage that are
on etherpad, they can be found at <http://hexm.de/2f>.
Now, my summary:
JS syntax errors affect other modules in ResourceLoader
http://bugzilla.wikimedia.org/28626
Brion filed this bug and we discussed what it would take to solve
it. To solve this one we'll have to find a GPL-compatible JSLint
work-alike. Anyone have one or know of one?
1205: Lock wait timeout exceeded; try restarting transaction (tracking)
http://bugzilla.wikimedia.org/28499
After getting reports of a few DB timeouts, we set up this
tracking bug and discovered during triage we didn't really have
any way to keep track of these errors. We gave Sam Reedy the job
of tracking down what is necessary to do this so that, in the
future, we'll have a better handle on exactly how bad problems are
when they appear.
Replace MD5 password hashing with WHIRLPOOL
http://bugzilla.wikimedia.org/28419:
I had retitled this bug base on Tim's idea. I used the triage to
help decide what sort of priority this should have. After a bit
of discussion we decided to let Tim set the priority and
(hopefully) implement his suggestion.
Animated GIF has black artifacts when scaled
http://bugzilla.wikimedia.org/28631
During Triage, we had a discussion about ImageMagick thumbnailing
in general and when this particular problem would come up Sam
again suggested VIPScalar as a thumbnailer replacement.
Brion suggested we might return to not providing thumbnails of
animated GIFs because of size problem since this particular problem
was the result of trying to thumbnail animated GIFs.
After triage, I found that removing the “+map” option from the
thumbnailing command removed the artifacts from the thumbnail and
produced a smaller image.
Merge iwtransclusion branch into phase3
http://bugzilla.wikimedia.org/28673
Even though this is an enhancement, and enhancements aren't
usually brought up in triage, I brought it up because so many
people have been looking for it and talking about it on
foundation-l, etc.
Sam said he has been working on merging the code, but Roan also
might need to help.
We'll still need to review it for architectural soundness.
In any case this probably won't make it in in time for 1.18.
Title attribute is missing for some internal links
http://bugzilla.wikimedia.org/28182
Brought this up because people have been complaining about it ever
since we deployed in February and I was actually responsible for
creating the complaints by fixing an old bug
(http://bugzilla.wikimedia.org/542).
After a bit of discussion about the problems of fixing old bugs —
something I'll remember forever — I said I would revert my fix.
(See http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87030)
{{DEFAULTSORT:}} trims leading space
http://bugzilla.wikimedia.org/28023
Comment from Triage: “This is a fairly esoteric case.” We are
lowering the priority.
Boldface all fatals (in the installer)
http://bugzilla.wikimedia.org/28039
MaxSem has fixed this one. (See
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87027)
Chad pointed out he plans to fix the entire warning system in
1.18.
Thumbnail feature in Special:listfiles doesn't handle very narrow
images well.
http://bugzilla.wikimedia.org/28076
Bryan has provided a patch and, after triage, Brion reviewed it.
Lucene search for simple text misses some results
http://bugzilla.wikimedia.org/25404
Search result snippets should skip parenthetical phrases
http://bugzilla.wikimedia.org/28088
During triage, we discussed how we can manage Search bugs since
they require some Java skills and messing with Lucene. I mostly
raised this just so we could talk about how to handle these search
problems more reliably since, till now, we've relied on a
volunteer who doesn't have as much time available.
Can't upload PDF / ODF Hybrid
http://bugzilla.wikimedia.org/28188
Another enhancement request. We talked about security checks on
PDFs and ZIPs and why we would want to support this. Updated the
bug with comments.
"Context per line" preference doesn't seem to do anything useful
http://bugzilla.wikimedia.org/28343:
We'll be obsoleting this pref since it doesn't do anything.
Edit tab is shown as "view source" for blocked users, which breaks squid caching
http://bugzilla.wikimedia.org/28354
P.Copp supplied a patch which I've asked him to apply.
Line breaks introduced when nesting nowiki within code tags.
http://bugzilla.wikimedia.org/28087
This Parsing bug targetted for Brion's newparser.
Till next week, enjoy the bugs!
Mark.
Hey everybody,
We have a new committer joining our ranks, lets give him a warm welcome.
Thenub314 - u/n: thenub314 - Extensions access, wants to work on texvc
-Chad
Just a quick check-in on the status of SSL access to Wikipedia...
We've still got the old SSL proxy on http://secure.wikimedia.org which
allows reaching most (hopefully all?) Wikimedia wikis over SSL on an
alternate URL, but Wikimedia ops currently considers this an 'unsupported'
service, which gives it a lower priority for fixes and keeps it off
status.wikimedia.org.
The general problems with it can be summed up under:
* SECURITY: most images and some scripts are still loaded over insecure
channels; some MITM vectors may remain.
* RELIABILITY: the actual proxy setup has performance/reliability &
maintainability issues
* HUMAN FACTORS: the alternate URLs are a pain for humans to deal with (and
make maintenance harder as matching rules often need to be adjusted)
I believe Ryan's working on improvements on the actual proxy setup and
maintenance.
It looks like styles and scripts are loaded fairly consistently through
secure.wikimedia.org, either via load.php (ResourceLoader) or index.php
(action=raw stuff using traditional importScript etc). There may be some bad
site, user, or gadget scripts that explicitly load code or styles over
non-SSL -- those if found should be fixed.
The only script I see loaded over non-SSL on a few random hits on English
Wikipedia are hits to http://geoiplookup.wikimedia.org
Some bugzilla entries with relevant issues:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=16822 --
upload.wikimedia.org needs SSL interface
That shouldn't be super-hard to set up in theory -- it doesn't need to use
the same domain name -- but of course it'll increase load on the SSL
proxies.
It looks like pretty much all on-wiki images get loaded via
http://upload.wikimedia.org currently, which can trigger mixed-mode content
warnings in some browsers. While it in theory doesn't have a huge direct
risk, images can be spied upon (attacker guesses what you're reading/doing
based on what images you're loading) or sometimes replaced with alternate
content (annoyance factor mostly).
* https://bugzilla.wikimedia.org/show_bug.cgi?id=27968 -- JavaScript (geoip
lookups) included via plain HTTP on HTTPS sites
This ought to again be a matter of making sure the service is reachable over
SSL and using it.
* https://bugzilla.wikimedia.org/show_bug.cgi?id=225 -- secure login on
wikimedia via ssl
While many of our sites have added custom helper links to send people to the
secure site from the login page, it's still optional, unofficial, and
inconsistently shown.
* https://bugzilla.wikimedia.org/show_bug.cgi?id=20643 -- Serve SSL/HTTPS
sites out of same domain names as HTTP access: https://en.wikipedia.org/
This'll need more work as it has to deal with the offsite proxies, multiple
domains, etc. But it's been on the slate for a long time and we did some
live experiments in 2007 that looked positive; if done it'll make the SSL
views of the site friendlier to use, and smart session/cookie management
could keep people form having to manually bounce themselves between SSL and
non-SSL links.
-- brion vibber (brion @ pobox.com)