Wikitech-l July 2011

wikitech-l@lists.wikimedia.org

96 participants
96 discussions

Help
by Steven Krein 11 Jul '11

11 Jul '11

Thanks, Steve ------------------ Steven Krein CEO OrganizedWisdom http://OrganizedWisdom.com 917-903-4288 @stevenkrein StartUp Health http://startuphealth.com On Jul 10, 2011, at 9:12 PM, wikitech-l-request(a)lists.wikimedia.org wrote: > Send Wikitech-l mailing list submissions to > wikitech-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > or, via email, send a message with subject or body 'help' to > wikitech-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > wikitech-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Wikitech-l digest..." > > > Today's Topics: > > 1. Re: testing mobile browsers? (Marco Schuster) > 2. Parser bugs and their priority (Mark A. Hershberger) > 3. Supporting Extension authors (Mark A. Hershberger) > 4. Re: all those zeros in tables in text brosers (Aryeh Gregor) > 5. Re: Parser bugs and their priority (MZMcBride) > 6. Re: testing mobile browsers? (Tomasz Finc) > 7. Re: testing mobile browsers? (Tomasz Finc) > 8. Re: ?Easy? Bug Triage meeting notes (MZMcBride) > 9. Re: Wikimedia engineering report for June 2011 (MZMcBride) > 10. Re: Wikimedia engineering report for June 2011 (Ryan Lane) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 9 Jul 2011 22:16:25 +0200 > From: Marco Schuster <marco(a)harddisk.is-a-geek.org> > Subject: Re: [Wikitech-l] testing mobile browsers? > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CAC6HepSnZjJ9gkU308hZO6eTCXz+Ew4ae5EsN1FkSwzrOfwo9Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sat, Jul 9, 2011 at 8:51 PM, H?kon Wium Lie <howcome(a)opera.com> wrote: >> Opera comes in two flavors for mobile devices: Opera Mini and Opera >> Mobile. Opera Mobile is, indeed, close to the desktop version in the >> sense that it runs the same display, javascript engine etc. on the >> device. > > The versions of Opera Mobile floating in the wild are kinda different. > Every HTC HD2 user with Windows Mobile 6.5 is likely to still run the > ages-old buggy HTC version (8.x AFAIR, compared to current v10!), as > the "official" versions STILL don't support the multi-touch features > even though libraries exist which abstract the multi-touch -.- > > Marco > > > > ------------------------------ > > Message: 2 > Date: Sat, 09 Jul 2011 17:01:33 -0400 > From: mhershberger(a)wikimedia.org (Mark A. Hershberger) > Subject: [Wikitech-l] Parser bugs and their priority > To: Wikitech List <wikitech-l(a)lists.wikimedia.org> > Message-ID: <87liw7dv82.fsf(a)everybody.org> > Content-Type: text/plain; charset=utf-8 > > > Recently, there was a discussion on a bug (?UNIQ key exposed? > https://bugzilla.wikimedia.org/14562) about the priority setting I had > given the bug. > > It was part of the problems I found in Bugzilla last December and > gathered into a tracking bug (https://bugzilla.wikimedia.org/26213). > > It looks like I made the wrong decision on #14562 since it was part of > an extension that, while deployed on enwiki, wasn't likely to be > triggered. > > When I was discussing this with Robla, he suggested I ask about this on > wikitech-l, so here goes: > > There are at least four bugs live on Wikipedia that leave really ugly > UNIQ strings in the wikitext. I've created a demonstration of them on > my wiki page: http://hexm.de/4x > > The bug numbers are on the page linked to their entry in Bugzilla. > > I suppose these are all linked to the parser work that Brion & co are > currently working on, but the arrival of the new parser 6 months to a > year or more away (http://www.mediawiki.org/wiki/Future/Parser_plan), > I'd like to get these sort of parser issues sorted out now. > > For those more familar with the current parser: how can those developers > who are less experienced start fixing the problem? How important are > these issues? > > Mark. > > > > ------------------------------ > > Message: 3 > Date: Sat, 09 Jul 2011 17:17:08 -0400 > From: mhershberger(a)wikimedia.org (Mark A. Hershberger) > Subject: [Wikitech-l] Supporting Extension authors > To: Wikitech List <wikitech-l(a)lists.wikimedia.org> > Message-ID: <87hb6vdui3.fsf(a)everybody.org> > Content-Type: text/plain; charset=utf-8 > > > MediaWiki.org is great for extension authors, as far as it goes. Today, > though, someone asked on #mediawiki how to create development branches > for their extension in their SVN repo. I told him I didn't think it > could be done ? that he might have to use the SVN repo as a backend to > push to from git or bzr ? but I'm not sure that answer was correct. > > Anyway, as I was writing about the UNIQ tracking bug, I thought of some > documentation and support that we should try to get in place for > extension developers. Since Sumana is creating a lot of good > documentation about testing lately, that is where I started: > > * What sort of things should they test? > > * Can they have tests that will continue to work against the current > parser and the next one? > > * How can they write parser tests and unit tests to try out their > code? > > * How can they make sure that those tests are run on the test server? > (I think this actually requires some work on the test server, but?) > > Of course, that documentation would help more than just the extension > writers who have ?UNIQ? showing up in their output. What else could we > do to support extension authors? > > Mark. > > > > ------------------------------ > > Message: 4 > Date: Sun, 10 Jul 2011 10:35:42 -0400 > From: Aryeh Gregor <Simetrical+wikilist(a)gmail.com> > Subject: Re: [Wikitech-l] all those zeros in tables in text brosers > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CAKA+AxmFMi9Q_Vd=TF+Xv8DRBwnwrmzLd5DPPi0sc7NeU4AP7g(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sat, Jul 9, 2011 at 3:49 AM, Niklas Laxstr?m > <niklas.laxstrom(a)gmail.com> wrote: >> It exists and it's called data-sort-value attribute. And it's already >> live on Wikipedia as far as I can see. > > data-* attributes are only valid in HTML5 and will not work until > $wgHtml5 is set to true. As has been discussed here a number of > times, it's been true on trunk continuously since r53142 (June 12, > 2009) and in releases since 1.16, but it hasn't yet been enabled on > Wikimedia sites. Apparently there are finally plans to try enabling > it for Wikimedia in the near future. > > > > ------------------------------ > > Message: 5 > Date: Sun, 10 Jul 2011 11:34:34 -0400 > From: MZMcBride <z(a)mzmcbride.com> > Subject: Re: [Wikitech-l] Parser bugs and their priority > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: <CA3F3ECA.12797%z(a)mzmcbride.com> > Content-Type: text/plain; charset="US-ASCII" > > Mark A. Hershberger wrote: >> Recently, there was a discussion on a bug ("UNIQ key exposed" >> https://bugzilla.wikimedia.org/14562) about the priority setting I had >> given the bug. > > [...] > >> I suppose these are all linked to the parser work that Brion & co are >> currently working on, but the arrival of the new parser 6 months to a >> year or more away (http://www.mediawiki.org/wiki/Future/Parser_plan), >> I'd like to get these sort of parser issues sorted out now. >> >> For those more familar with the current parser: how can those developers >> who are less experienced start fixing the problem? How important are >> these issues? > > Bugs have a habit of setting their own priority. If these bugs were > regularly being hit by users, they would have been resolved ages ago (in > theory!). But they only appear in very, very strange edge cases, which have > the lowest user impact (not quite zero, but slightly above). > > My recommendation would be to add some parser tests for these bugs, mark > them as failing, and if the rewrite doesn't take care of them, re-examine > them then. There are so many more bugs that are affecting so many people. > The fact that you can't combine three types of esoteric wiki syntax in > certain ways currently really shouldn't be a very high concern. > > I think that's roughly what Tim was trying to say. > > MZMcBride > > > > > > ------------------------------ > > Message: 6 > Date: Sun, 10 Jul 2011 12:57:52 -0700 > From: Tomasz Finc <tfinc(a)wikimedia.org> > Subject: Re: [Wikitech-l] testing mobile browsers? > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CAMxhqbduBc8AbVgWTYOc=xPQVORwpUyw44osfNc1-HYSPTZ1sw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > That would be awesome to get in. I've been meaning to chat with Timo > about this. Let me see if there are any others that were seeing. > > --tomasz > > On Sat, Jul 9, 2011 at 2:30 AM, Ashar Voultoiz <hashar+wmf(a)free.fr> wrote: >> Hello, >> >> Our javascript tests are being run under TestSwarm [1] and we currently >> cover up most desktop browsers (thanks brion). >> >> According to our squids stats [2], most of Wikimedia mobile traffic >> comes from the following browsers (sorted by popularity): >> ? - Safari >> ? - Android >> ? - Opera >> ? - Mozilla >> ? - Blackberry >> >> * Safari, Opera & Mozilla for mobile : they are probably mostly the same >> as the desktop version. I have not found emulators for them. >> * Android : has an emulator. On my computer it is painfully slow and not >> usable for anything. >> * Blackberry : emulator is Windows only :-/ >> >> Would be great to enhance our testswarm with more browsers. Maybe we >> could contact those mobiles developers to connect to our testswarm? >> >> :-) >> >> >> [1] http://toolserver.org/~krinkle/testswarm/ >> [2] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm >> >> -- >> Ashar Voultoiz >> >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > > > ------------------------------ > > Message: 7 > Date: Sun, 10 Jul 2011 12:58:50 -0700 > From: Tomasz Finc <tfinc(a)wikimedia.org> > Subject: Re: [Wikitech-l] testing mobile browsers? > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CAMxhqbesgRQpzAo50VEDhH+tFHruiG18nWO9VHakH0DebDJa3Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sat, Jul 9, 2011 at 11:51 AM, H?kon Wium Lie <howcome(a)opera.com> wrote: >> Also sprach Ashar Voultoiz: >> >> ?> Our javascript tests are being run under TestSwarm [1] and we currently >> ?> cover up most desktop browsers (thanks brion). >> ?> >> ?> According to our squids stats [2], most of Wikimedia mobile traffic >> ?> comes from the following browsers (sorted by popularity): >> ?> ? ?- Safari >> ?> ? ?- Android >> ?> ? ?- Opera >> ?> ? ?- Mozilla >> ?> ? ?- Blackberry >> ?> >> ?> * Safari, Opera & Mozilla for mobile : they are probably mostly the same >> ?> as the desktop version. I have not found emulators for them. >> >> Opera comes in two flavors for mobile devices: Opera Mini and Opera >> Mobile. Opera Mobile is, indeed, close to the desktop version in the >> sense that it runs the same display, javascript engine etc. on the >> device. >> >> Opera Mini runs these engines in server parks in the fixed network and >> tranfers a binary representation to a small viewer on the device. We >> currently process around 60 billion pages per month and Wikipedia is >> typically in the top 10 lists in the top 20 countries we publish >> statistics for: >> >> ?http://www.opera.com/smw/2011/05/ >> >> In the test swarm link you sent, Opera 10 and 11 are listed, but >> not Opera Mini (which is currently at version 6). Could it be that >> your sniffer doesn't pick up Opera Mini users? >> >> ?http://toolserver.org/~krinkle/testswarm/ >> >> Here a sample UA string from a recent version of Opera Mini: >> >> ?Opera/9.80 (Android; Opera Mini/6.24556/25.657; U; en) Presto/2.5.25 Version/10.54 >> >> And here's the Opera Mini emulator: >> >> ?http://www.opera.com/mobile/demo/ >> >> While Wikipedia remains popular with Opera Mini users, there is a >> technical problem which limits the user experience. Wikipedia uses >> JavaScript to unfold sections in articles. Alas, executing JavaScript >> requires a rountrip to the server (the Opera Mini server, that is) >> which takes time and costs money. It would be better if articles were >> unfolded by default for Opera Mini users. > > Open bug already in place .. any takers? > > https://bugzilla.wikimedia.org/show_bug.cgi?id=29517 > > --tomasz > > > > ------------------------------ > > Message: 8 > Date: Sun, 10 Jul 2011 16:35:57 -0400 > From: MZMcBride <z(a)mzmcbride.com> > Subject: Re: [Wikitech-l] ?Easy? Bug Triage meeting notes > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: <CA3F856D.127C1%z(a)mzmcbride.com> > Content-Type: text/plain; charset="US-ASCII" > > Sumana Harihareswara wrote: >> On 07/08/2011 02:20 PM, Mark A. Hershberger wrote: >>> Still, despite the problems, hosting the triage in IRC meant that some >>> developers interested in MediaWiki that Sumana invited were able to >>> watch and volunteer developers were able able to participate. >> >> Mark: Thanks, as always, for running this triage. I have now added the >> relevant bugs to >> >> http://www.mediawiki.org/wiki/Annoying_Little_Bug >> >> which you should feel free to hand out to developers interested in >> writing their first MediaWiki patch. > > I sporadically made a complementary page (without references) at > <http://www.mediawiki.org/wiki/Annoying_large_bugs> which lists more complex > (and more exciting) bugs. > > The "easy" bugs list is nice, but it doesn't really spark much creative > energy. A second page with more exciting (but harder to implement) bugs > seemed appropriate. :-) > > I tried to list bugs that a lot of users are more likely to encounter, both > on Wikimedia wikis and on their personal MediaWiki installs. > > MZMcBride > > > > > > ------------------------------ > > Message: 9 > Date: Sun, 10 Jul 2011 21:09:01 -0400 > From: MZMcBride <z(a)mzmcbride.com> > Subject: Re: [Wikitech-l] Wikimedia engineering report for June 2011 > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: <CA3FC56D.127D2%z(a)mzmcbride.com> > Content-Type: text/plain; charset="ISO-8859-1" > > Guillaume Paumier wrote: >> The report of Wikimedia engineering activities for June 2011 is now available: >> >> Blog version: >> http://blog.wikimedia.org/2011/07/01/engineering-june-2011-report/ >> Wiki version: >> http://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/June > > [quote] > Summer of Research 2011 > <http://meta.wikimedia.org/wiki/Research:Wikimedia_Summer_of_Research_2011> > ?? Asher Feldman and?Ryan Lane > <http://www.mediawiki.org/wiki/User:Ryan_lane> ?created the systems > infrastructure for the Summer of Research team to perform data mining and > analysis work. > [/quote] > > Do you have more info about this? It sounds like they're duplicating the > Toolserver, but it's hard to say without knowing more. > > MZMcBride > > > > > > ------------------------------ > > Message: 10 > Date: Sun, 10 Jul 2011 20:12:13 -0500 > From: Ryan Lane <rlane32(a)gmail.com> > Subject: Re: [Wikitech-l] Wikimedia engineering report for June 2011 > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: > <CALKgCA3zuZbGOQYfrwDB--Ju1Rt0f5w0ce6FEMRQHjD7VcqGeQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > >> [quote] >> Summer of Research 2011 >> <http://meta.wikimedia.org/wiki/Research:Wikimedia_Summer_of_Research_2011> >> ?? Asher Feldman and?Ryan Lane >> <http://www.mediawiki.org/wiki/User:Ryan_lane> ?created the systems >> infrastructure for the Summer of Research team to perform data mining and >> analysis work. >> [/quote] >> >> Do you have more info about this? It sounds like they're duplicating the >> Toolserver, but it's hard to say without knowing more. >> > > They need access to information not available on the toolserver. This > is just a single virtual machine that has mysql access to a database > replica. > > - Ryan > > > > ------------------------------ > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > End of Wikitech-l Digest, Vol 96, Issue 12 > ******************************************

1 0

“Easy” Bug Triage meeting notes
by mhershberger＠wikimedia.org 11 Jul '11

11 Jul '11

This past Wednesday, we had our second IRC triage. The focus was on triaging bugs marked “easy”, verifying that they were still bugs and making sure they were actually something a new coder could do. This meant we had a larger number of bugs to cover. I had planned only 2 minutes per bug in order to get through all of them in an hour which caused problems. This short time limit created some problems which means I'll have to be careful to restrict the number of bugs in the future, or tell people the time for the triage will be longer than one hour. Still, despite the problems, hosting the triage in IRC meant that some developers interested in MediaWiki that Sumana invited were able to watch and volunteer developers were able able to participate. Before talking about the ones that are already done or that we decided were not something a new developer should attempt, I'll give you the list of bugs that we confirmed as “easy”: http://bugzilla.wikimedia.org/25909 Add a drop-down list for the tags in RecentChanges and NewPages http://bugzilla.wikimedia.org/26470 Add toggle for checkered or transparent image background on file description pages http://bugzilla.wikimedia.org/28162 Installer does not respect initial DBport declaration http://bugzilla.wikimedia.org/28173 Postgres defaults to a unix socket - mention in install? http://bugzilla.wikimedia.org/28296 Installer should honor &uselang= parameter http://bugzilla.wikimedia.org/28981 handle diffonly param on diffs between deleted revision http://bugzilla.wikimedia.org/29110 $wgFeedDiffCutoff doesn't affect new pages http://bugzilla.wikimedia.org/29311 [OutputPage] Create a method to remove items from mModules http://bugzilla.wikimedia.org/19295 Navigation headings should not be lower-cased in German (and other languages) http://bugzilla.wikimedia.org/8178 [low enhancement] Make table of contents for category pages: Subcategories, Pages, Media http://bugzilla.wikimedia.org/21511 Document all configuration variables (usable in LocalSettings.php) By walking through bugs in this way, we were able to close a few right away as invalid or already fixed: http://bugzilla.wikimedia.org/23442 javascript error in examine mode http://bugzilla.wikimedia.org/27394 Message "lastmodifieddat" should be in user language instead of for content http://bugzilla.wikimedia.org/27047 Nicer design for pre elements in Vector http://bugzilla.wikimedia.org/25839 Add class for block ending time <span> element http://bugzilla.wikimedia.org/22770 wrap rights on GlobalGroupPermissions into a CSS class (Had a patch that looked usable, but yesterday, after the triage, DieBuche pointed out that creating a new CSS class wasn't necessary.) These next ones had patches that needed to be to be reviewed and applied: http://bugzilla.wikimedia.org/28838 Remove redundant IE-CSSFix rules from monobook/main.css Applied in r91742 http://bugzilla.wikimedia.org/28147 MediaWiki:Centralauth-login-global - rewording suggested to make it more concrete. Applied in r91706, fixed up by SPQRobin in r91733. http://bugzilla.wikimedia.org/27894 Move edit on double-click event listener down to div#bodyContent Brion and Krinkle have been reviewing the patch but since the original submitter hasn't replied for 2 months (despite other recent activity on the bug), this is a good place for another developer to jump in and take over the work. Of course, when you're looking over “easy” bugs, some of them get fixed soon after: http://bugzilla.wikimedia.org/23086 [extensions] AbuseFilter config diff date and time should use user preference instead of UTC SPQRobin fixed in r91619 And then there were the ones that were marked “easy” but, after discussion, really weren't: http://bugzilla.wikimedia.org/13862 Add a horizontal table of contents to Special:SpecialPages http://bugzilla.wikimedia.org/20781 Move 'mainpagetext' message to installer's .i18n file once it exists (Yes, this is easy, Except that it needs coordination with Translatewiki.net. If we could move all of the MessagesXX translations to Installer.i18n.php in one move, it wouldn't cause any headaches for translators.) http://bugzilla.wikimedia.org/24159 Remove uses of the error suppression operator (Most of the low hanging fruit has been done here. The ones remaining can be a bit remaining can be a bit tricky.) http://bugzilla.wikimedia.org/27501 List categories from foreign file repositories on the File description page (Need to rewrite the way the description page is fetched from the foreign repo. Can be done via the API.) http://bugzilla.wikimedia.org/27545 Extension:reCAPTCHA has badly worded message http://bugzilla.wikimedia.org/12532 File links on image description page should be in alphanumeric (alphabetic) order (Could be easy, but requires one to make sure you don't do something stupid with the db query. A-Z Sorting all linked pages is slow/unindexed, sorting only the first (random) 200 entries is confusing for the user.) http://bugzilla.wikimedia.org/29290 continue does not work in same cases for prop=iwlinks&iwcontinue and list=iwbacklinks&iwblcontinue http://bugzilla.wikimedia.org/26597 Allow toggling of persistent cookies ("remember me") in API action=login (Sam's initial fix was reverted, so maybe not so easy.) Thanks, everyone, for helping out! Mark.

3 2

all those zeros in tables in text brosers
by jidanni＠jidanni.org 10 Jul '11

10 Jul '11

I don't see why Wikipedia looks 99% fabulous in lynx and w3m, but blows it on such a simple thing like dates in tables, $ lynx -dump http://en.wikipedia.org/wiki/List_of_social_networking_websites Please note the list is not exhaustive, and is limited to notable, well-known sites. Name Description/Focus Date launched [12]Registered users Registration Global [13]Alexa^[14][1] Page ranking [15]Academia.edu Social networking site for academics/researchers 02008-09-01September 2008 &0000000000211000000000211,000^[16][2] Open &00000000000092940000009,294^[17][3] [18]Advogato [19]Free and [20]open source software developers 01999 1999 &000000000001357500000013,575^[21][4] Open... Why can't they go that extra one percent and clean all those silly zeros out of their tables? Yes those stubborn text browser users should be denied extra features, but can't they at least be given something readable. Search engines would thank you too. Sure you can say "not a MediaWiki problem, go contact the website", but if MediaWiki gave them the proper tools to make their templates, they wouldn't need to make such a mess.

5 5

Welcoming Ian Baker
by Alolita Sharma 09 Jul '11

09 Jul '11

Hi All, Please join me in welcoming Ian Baker as Software Developer in the Features Engineering team. Ian's been a software developer for about 15 years. He's worked on projects like the first open-source web framework, a billing system for a regional ISP, a custom video transcoding system, and a sensor-based flamethrower controller. At Wikimedia Foundation, he hopes to code some awesome features, help find new ways for people to share and connect information, help improve the overall Mediawiki user experience, and advance the codebase towards present-day software development practices. Specific interests include data model design, database query optimization, regular expressions, user interfaces, human computer interaction and online communities. Ian has been building large-scale installation art since 2005, and has taught flame effects, fire performance, and fire safety classes at The Crucible and elsewhere since 2006. Ian is a founding member of the art collective Ardent Heavy Industries, including its fire art wing, Interpretive Arson. In other lifetimes, he’s worked as a broadcast engineer, welder, machinist, fire performer, drug educator, EMT, and photographer. And he also enjoys flower arrangement and aerial acrobatics. Wow - that’s a lot of cool interests :-) Feel free to say hello to Ian online or in person at WMF Engineering in San Francisco. Welcome Ian! -- Alolita Sharma Features Engineering Wikimedia Foundation

6 5

wiki markup lacks HTML precision anchors
by jidanni＠jidanni.org 09 Jul '11

09 Jul '11

While I would not list the Mediawiki language as a 'crap' language, I still think it is regretful that one cannot achieve the precision of an HTML <a name="bla"> anchor, to say, make a link to a spot anywhere within a page, whereas with the Mediawiki language, the best one can do is link to the top of a table for example, http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials instead of also to a random point within say, giant tables.

6 6

The non-coder friendly weekend sprint: Check pre-1.17 bugs
by mhershberger＠wikimedia.org 09 Jul '11

09 Jul '11

This week, Sumana said she had some people who were interested in looking at old bugs to see if they were still reproducible under 1.17. I decided to steal this idea for a great weekend sprint that even people who are not developers could take part in: Help me look at these bug reports and see if the problems they describe are still reproducible or if the problem has been fixed. If you don't have a test wiki with 1.17 installed, then you can try to reproduce a lot of these on Wikipedia in your user sandbox. If you don't have one yet, you can use this link to load one: http://hexm.de/4w If you come across one that you don't know how to reproduce in your user sandbox or on your own wiki, then add the keyword “testme”. With that out of the way, there are plenty of bugs to test. Here are a few ways to find a good candidate for testing: * There are currently 616 bugs that are explicitly filed against pre-1.17 versions of MediaWiki: http://hexm.de/4e * If you modify the query to remove those bugs labeled “enhancement”, you'll end up with 345 bugs: http://hexm.de/4j * Some bugs just have “unspecified” as the version. There are 1747 MW that were created before 2011-06-22 (1.17's release date) with “unspecified” as the version number: http://hexm.de/4f * Again, if you remove the ones labeled “enhancement”, you come up with 526 bugs: http://hexm.de/4g You can do all sorts of things to reduce the list to nice bite-sized chunks. Here, for example are smaller lists of bugs marked “normal” or higher severity for each version of MW in bugzilla: 1.6.x (11 bugs) http://hexm.de/4k 1.7.x (5 bugs) http://hexm.de/4l 1.8.x (3 bugs) http://hexm.de/4m 1.9.x (14 bugs) http://hexm.de/4n 1.10.x (17 bugs) http://hexm.de/4o 1.11.x (23 bugs) http://hexm.de/4p 1.12.x (20 bugs) http://hexm.de/4q 1.13.x (21 bugs) http://hexm.de/4r 1.14.x (26 bugs) http://hexm.de/4s 1.15.x (42 bugs) http://hexm.de/4t All 1.16 versions (94 bugs) http://hexm.de/4v I'm fascinated by the jump from 26 bugs version 1.14 to 42 bugs in version 1.15 and then the big bounce to 94 bugs in 1.16 and think this is a good area to dig into. I'm interested in *why* that is there, whether it is because of more people checking, better reporting, or (hopefully not) worse solving. Of course, we still need people to look at the “testme” bugs, too: http://hexm.de/4i Finally, if you have followed the steps in the bug and can't reproduce it, please mark it “FIXED”. Comments are always helpful on the bugs, so leave one if you have a question or comment about the bug. Happy Testing! Mark.

3 3

Heads-up: WMF engineering process improvement meetings
by Erik Moeller 08 Jul '11

08 Jul '11

Hi folks, this is a heads-up that Tomasz, Rob, Alolita, CT, Brion, Roan[TBC], Howie and I will be meeting with ThoughtWorks ( http://en.wikipedia.org/wiki/ThoughtWorks ) Thursday and Friday. Rob and I also got a download from Tim ahead of time. ThoughtWorks has done great work with the fundraising developers (Arthur, Katie, Kaldari) already in helping protect that team from distractions, prioritize its work, and ensure that roles/responsibilities are clearly understood vis-a-vis the fundraising folks in the community department. So, we're now exploring a deeper engagement with ThoughtWorks on problem-solving across the engineering organization. Following initial conversations, the purpose of the meeting tomorrow is to do a deep-dive into a specific problem set: the code review, deployment and release management process. We'll be digging into questions like: 1) What are the best methods to ensure we keep up with the backlog while still maintaining a good clip of WMF priority development; 2) What's a realistic deployment and release cycle to shoot for (for trunk, extensions, branches); 3) How do we dissipate key skills more widely among both staff and volunteers (e.g. deployment, security reviews); 4) How/when can we split "big hairy projects" with integration issues into more manageable chunks; 5) What other high priority improvements do we need to prioritize (e.g. increased test coverage, improvements to the testing frameworks, het-deploy, staging environments, etc.) We're intentionally keeping this first meeting at a manageable size to have a high face-to-face throughput and to explore where ThoughtWorks can best help us. But I'm very much intending to make our thinking public, and to form clear and visible groups around core problems we're tackling, just as we have been doing with all WMF engineering projects. So, I'll keep you posted, and if you have thoughts that you'd like to post ahead of time, please do it onlist or offlist :-) Thanks, Erik -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

4 3

Bug solving metric?
by Tim Landscheidt 08 Jul '11

08 Jul '11

Hi, is there any metric defined to see how the bug solving pro- cess has improved over time? The main reason I'm asking is today's two mails regarding bug #24000 ("Update rsvg so styling SVG images with CSS works properly on Commons"). Reported more than a year ago, the solution found early on was to update rsvg. I would have suspected that to do that you execute an "rpm -Uvh" equiva- lent on the server farm and close the bug. Yet for months nothing happened at all, and then some keywords were added, removed and replaced. From an outside perspective, this looks like (much) more energy is spent on managing the bugs than actually squashing them. But that of course is not only an outside perspective, but the biased view of a user who is affected by the bug, sees a possible solution on his screen and experiences the helplessness of being at the mercy of someone else :-). So is there any "scorecard" with more detailed data than the weekly report, i. e. minimum/average/maximum time to closure of bugs/non-bugs, some nice visualizations, etc.? TIA, Tim

2 1

Wikipedia dump (20110620) is 5.8G whereas previous dump(20110526) is 6.8G
by Sezgin Sucu 08 Jul '11

08 Jul '11

Hi, The dump under "Recombine articles, templates, image descriptions, and primary meta-pages" is 6.8GB in http://dumps.wikimedia.org/enwiki/20110526/ page, whereas the same dump here http://dumps.wikimedia.org/enwiki/20110620/ page is 5.8GB. To be more accurate: http://download.wikimedia.org/enwiki/20110620/enwiki-20110620-pages-article… (5.8GB) vs http://download.wikimedia.org/enwiki/20110526/enwiki-20110526-pages-article… (6.8GB) Any idea why we have such a big difference? Thanks

2 1

Re: [Wikitech-l] [Selenium] IDE test for regressing bug
by Michelle Knight 08 Jul '11

08 Jul '11

Hi Sumana, Sure I would be interestd in writing tests with other tools. I like the record and play option in Selenium IDE to get a feel for the code. I am seeing that TestSwarm is a possible tool that the developers are using. Is there a tool with more of a record and play option, that will not interfere with the pages, to use and become familiar with the code? Feel free to email me offline too. Michelle Knight ------------------------------ Message: 4 Date: Thu, 7 Jul 2011 11:23:30 -0400 From: Sumana Harihareswara <sumanah(a)wikimedia.org> Subject: Re: [Wikitech-l] [Selenium] IDE test for regressing bug https://bugzilla.wikimedia.org/show_bug.cgi?id=29310 To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, mknight1130(a)gmail.com Message-ID: <CAJwy5OXpNu1uC=5=vGz7kzdCbP2zLY5eYNuGFHCKViXmk5XaWA(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Michelle: Thanks for the test & test suite! Just wanted to update you that it seems like fewer and fewer MediaWiki developers are interested in Selenium tests, and many are moving to other tools for automatic testing: http://www.mediawiki.org/wiki/Requests_for_comment/Unit_testing http://www.mediawiki.org/wiki/Test_framework_deployment#Status:_Permanent_h… http://www.mediawiki.org/wiki/Selenium_Framework#Selenium.27s_uses_.26_flaws Would you be interested in writing test suites or tests for some of these other tools? Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2011