Wikitech-l November 2018

wikitech-l@lists.wikimedia.org

51 participants
71 discussions

Fwd: [Wikidata] The WikiCite 2018 program is live
by Pine W 16 Nov '18

16 Nov '18

Forwarding to other email lists which may have subscribers who are interested. Pine ( https://meta.wikimedia.org/wiki/User:Pine ) ---------- Forwarded message --------- From: Dario Taraborelli <dtaraborelli(a)wikimedia.org> Date: Fri, Nov 16, 2018 at 8:05 PM Subject: [Wikidata] The WikiCite 2018 program is live To: <wikicite-discuss(a)wikimedia.org>, Discussion list for the Wikidata project. <wikidata(a)lists.wikimedia.org> The program of WikiCite 2018 <https://meta.wikimedia.org/wiki/WikiCite_2018> (Berkeley, 27-29 November 2018) is now available <https://meta.wikimedia.org/wiki/WikiCite_2018/Program>. The plenary sessions and the tutorials will be recorded and we're looking into the possibility of making a livestream available. Dario -- on behalf of the organizing committee <https://meta.wikimedia.org/wiki/WikiCite_2018#Organizing_committee> wikicite(a)wikimedia.org _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

1 0

Holding 1.33.0-wmf.4
by Antoine Musso 14 Nov '18

14 Nov '18

Hello, I am holding deployment of 1.33.0-wmf.4 to the Wikimedia infrastructure. Some code path attempts to retrieve a memcached entry using an empty string as a key. It is most probably going to cause major issues if we keep pushing the train. The task is: https://phabricator.wikimedia.org/T209429 memcached error: A BAD KEY WAS PROVIDED/CHARACTERS OUT OF RANGE It originates from MemcachedPeclBagOStuff::checkResult() which logs an error albeit without any context. Probably adding an exception context would give us a stacktrace and thus find the faulting code. -- Antoine "hashar" Musso

1 1

Content Negotiation Protocol for Parsoid HTML in the REST API
by Subramanya Sastry 14 Nov '18

14 Nov '18

Hello everyone, The Core Platform and Parsing teams at the Wikimedia Foundation are glad to announce the implementation of a content negotiation protocol for Parsoid HTML in the REST API [1]. This was deployed to the Wikimedia cluster on October 1, 2018. TL;DR ----- Parsoid HTML clients can now use the Accept header to specify which version of content they expect when requesting Parsoid HTML from the REST API. If omitted, as before, they will get whatever version of the HTML is in storage, regardless of any breaking changes it may contain. Parsoid's HTML is versioned --------------------------- An advantage of Parsoid’s HTML output is that it is both specced and versioned [2]. By adhering to the principles of semantic versioning [3], Parsoid can signal to clients what kinds of changes can be expected in the output between versions. However, until recently, Parsoid always returned the latest version of its HTML. Naturally, this posed challenges when deploying breaking changes since clients had to be prepared to consume the newer version. Rolling out new HTML versions without breaking clients ------------------------------------------------------ Throughout its history, Parsoid developers have had close enough contact with the developers of Parsoid clients (they are internal to the Wikimedia Foundation for the most part) to coordinate deployment of breaking changes to the HTML. This mainly involved ensuring all known clients were forward and backwards compatible with the newer HTML version before deploying the change. Needless to say, as more clients were coming along, this informal process would not suffice; a scalable and predictable version upgrade solution was needed. Content Negotiation Protocol ---------------------------- To solve this problem, a content negotiation protocol [4] relying on HTTP Accept headers was implemented. See RESTBase’s documentation [5] for the exact details of the protocol. What follows is just an informal description. Parsoid clients are expected to pass an Accept header that specifies the HTML version they can handle. If the version present in storage does not satisfy the request, RESTBase will attempt to resolve the inconsistency. However, if the requested version cannot be satisfied, an (HTTP 406) error will be returned. The meaning of “satisfied” here mostly follows semver’s caret semantics [6] (the main difference being that the patch level is ignored). If a client does not pass the Accept header, everything works exactly like before, with all the downsides of the previous behaviour: no protection from breaking changes; you get whatever HTML version is currently in storage. Caveat emptors -------------- The deployed Parsoid version generates HTML versions 1.8.0 [7] and 2.0.0 [8]. But, it is worth mentioning that the oldest acceptable version supported is 1.6.0, so if you’re sending an Accept header with a version less than 1.6.0, your application will break. The reason for this odd constraint is that we mistakenly released that version without bumping the major version [9] even though it introduced a breaking change. Mea culpa! Also, RESTBase only stores the latest version so, as content gets rerendered and storage gets replaced, clients requesting older content have to pay a latency penalty while the stored content is downgraded to an appropriate version. Hence, we encourage Parsoid HTML clients to pay attention to announcements about major version changes and upgrade promptly. Going forward, we’ll send announcements about Parsoid HTML versions changes on the mediawiki-api-announce mailing list. How does this impact 3rd party wikis? ------------------------------------- Finally, astute readers will have noted that this announcement is concerning the REST API. However, many 3rd party installs have VE communicating directly with Parsoid and may be wondering how they’ll be impacted by the change. Parsoid has had a similar protocol (the difference is mainly in respecting the patch level) implemented since the v0.9.0 release [7]. So, going forward, when upgrading Parsoid or VE, if the HTML version requested by VE can be provided by Parsoid, the upgrade will be safe. In Conclusion ------------- Content negotiation now allows us to deploy new Parsoid features to the Wikimedia cluster without needing prior coordination with all clients. Clients can continue to request older versions until they are ready to update (assuming they don’t fall too far behind since we only plan on supporting two major versions concurrently). And, conversely, they can request newer versions with the guarantee that they will not receive incompatible content. [1]: https://phabricator.wikimedia.org/T128040 [2]: https://www.mediawiki.org/wiki/Specs/HTML [3]: https://semver.org/ [4]: https://tools.ietf.org/html/rfc7231#section-5.3 [5]: https://www.mediawiki.org/wiki/API_versioning#Content_format_stability_and_… [6]: https://www.npmjs.com/package/semver#caret-ranges-123-025-004 [7]: https://www.mediawiki.org/wiki/Specs/HTML/1.8.0 [8]: https://www.mediawiki.org/wiki/Specs/HTML/2.0.0 [9]: https://lists.wikimedia.org/pipermail/mediawiki-l/2018-March/047337.html

1 0

2018-11-14 Scrum of Scrums meeting notes
by Grace Gellerman 14 Nov '18

14 Nov '18

*https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-11-14 <https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-11-14>* *=2018-11-14=* == Callouts == * Release Engineering ** 1.33.0-wmf.4 deployment blockers https://phabricator.wikimedia.org/T206658 *** memcached error: A BAD KEY WAS PROVIDED/CHARACTERS OUT OF RANGE https://phabricator.wikimedia.org/T209429 * Weird writes to codfw kafka cluster: https://phabricator.wikimedia.org/T207994 == Audiences == === Contributors === ==== Community Tech ==== * Blocked by: * Blocking: * Updates: ** ==== Anti-Harassment Tools ==== * Blocked by: * Blocking: * Updates: ** ==== Editing ==== * Blocked by: * Blocking: ** Updates: ** ==== Growth ==== * Blocked by: * Blocking: * Updates: ** ==== Language ==== * Blocked by: * Blocking: * Updates: ** === Readers === ==== iOS native app ==== * Blocked by: * Blocking: * Updates: **breaking down the editing work ( https://phabricator.wikimedia.org/tag/ios-app-v6.2-beluga-on-a-pogo-stick/) **preparing for fundraising ==== Android native app ==== * Blocked by: * Blocking: * Updates: ** ==== Readers Web ==== * Blocked by: * Blocking: * Updates: ** Summary: We're performing a staged rollout of SEO changes, continuing the MobileFrontend investment project, and trying to wrap up Proton and page issues projects. ** Mobile website (MinervaNeue / MobileFrontend): *** Invest in the MobileFrontend & MinervaNeue frontend architecture https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFro… **** Merge mobile.references and mobile.references.gateway ResourceLoader modules T207805 **** Remove unused MW configs loaded on desktop pageviews T186062 **** T206699 Add tests for Button, Panel and Section **** Improve View composition T209007 **** Increase test coverage for non-View files with 0% coverage T206698 **** MobileFrontend pre-commit hooks don't work on Windows T208143 *** Page issues https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues **** [Research 4hrs] [Bug] Page issues link overlapping in multiple languages for larger screens T206887 **** Feature flag the page issues code T206179 **** Prepare selenium browser test for page issues A/B test T206647 *** Allow users to change their mobile skin preference T173527 *** Maintenance and bug fixes T202557 T99009 ** SEO: *** Old page_random values are nonuniformly distributed T208909 (Thanks Gergő Tisza, Tilman Bayer, Piotr Miazga, Sam Smith, Tim Starling, Brad Jorsch, Alex Monk, Brion Vibber, Daniel Kinzler, Max Semenik) *** Staged rollout for SEO A/B test T208755 ** PDF rendering (Proton) https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality *** Allow BBPromise cancellation T209070 *** Rewrite Queue to Promises T204055 *** Remaining work tracked in T186748 ==== Readers Infrastructure ==== * Blocked by: * Blocking: * Updates: ** Maps: *** The Stretch upgrade/data loading on the maps cluster continues ( https://phabricator.wikimedia.org/T205462 ) **** Some performance changes were made this week to help speed up the process ** ReadingLists: *** Batched deletion queries to give more predictable performance ( https://phabricator.wikimedia.org/T189926 ) ** MCS/PCS: *** Still working on improving performance by breaking up CPU-intensive work (https://phabricator.wikimedia.org/T202642 ) *** Working with the app teams on end-of-year fundraising announcements ( https://phabricator.wikimedia.org/T204821 ) *** Working on feed endpoint, adding attributes to 'Picture of the day" ( https://phabricator.wikimedia.org/T202311 ) ==== Multimedia ==== * Blocked by: * Blocking: * Updates ** Main focus continues to be on Structured Data on Commons, getting file captions live on production Commons https://phabricator.wikimedia.org/T194750 *** Thanks to colleagues in the Core Platform/MCR virtual team for work on anti-vandalism extension support. *** Still need progress on the https://phabricator.wikimedia.org/T194046 and https://phabricator.wikimedia.org/T200915 MCR tasks for https://phabricator.wikimedia.org/T205891 ==== Parsing ==== * Blocked by: * Blocking: * Updates: ==== UI Standardization ==== * Blocked by: * Blocking: * Updates: ** OOUI v0.29.4 & 0.29.5 got released last week, 0.29.3 before (missed SoS last week, therefore mentioning now), highlights: *** TagMultiselectWidget becomes invalid if there's text in input & there's a `tagLimit` option now, thx Tchanders *** Icon-only ButtonWidgets can carry a “waterproof” accessible label since 0.29.3, that's only visible for screen readers! - You only have to add a label as usual and additional config option `invisibleLabel: true` - Updating documentation on mediawiki.org – https://www.mediawiki.org/wiki/OOUI *** Accessibility measurements across products, like MobileFrontend and portals == Technology == === Analytics === * Blocked by: * Blocking: * Updates: ** Legacy Wikistats home page now links to wikistats2, deprecated older reportcard completely: http://stats.wikimedia.org ** Upgraded cluster to cloudera 5.15 distro which solved several security issues. Nobody noticed upgrade happened so SUCCESS. ** Refactoring our privacy policy data deletion scripts for safety [wiki, email] ** We run into quite an issue when calculating the reconstruction of mw history this month, there was a major refactor on mediawiki that we did not know happened (comment tables) and the way that data is surfaced on labs is very non optimal for analytics use cases. Working with core team/DBAa on finding a better way to expose comment data: https://phabricator.wikimedia.org/T209031 [wiki,email] === Cloud Services === * Blocked by: * Blocking: * Updates: ** === Fundraising Tech === * Blocked by: * Blocking: * Updates: ** CiviCRM optimizations, bug fixes and new reports ** More cleanup from PayPal's recurring payment ID changes ** Continuing CentralNotice backend work ** Supporting another card processor in Perú and Uruguay ** Testing backup card processor for US and Canada === MediaWiki Core Platform === * Blocked by: * Blocking: * Updates: ** === Performance === * Blocked by: ** * Blocking: ** * Updates: ** === Release Engineering === * Blocked by: ** 1.33.0-wmf.4 deployment blockers https://phabricator.wikimedia.org/T206658 *** memcached error: A BAD KEY WAS PROVIDED/CHARACTERS OUT OF RANGE https://phabricator.wikimedia.org/T209429 * Blocking: * Updates: ** === Research === * Blocked by: None * Blocking: None * Updates: ** Working on the "Crosslingual Section Alignment in Wikipedia" paper ** Researching ways of resolving interlanguage conflicts for article recommendations === Scoring Platform === * Blocked by: * Blocking: * Updates: === Search Platform === * Blocked by: * Blocking: * Updates: ** Fixed issue with highlighter breaking surrogate pairs: https://phabricator.wikimedia.org/T208736 ** Setting up A/B test for new wikidata completion models: https://phabricator.wikimedia.org/T209402 ** RDF ontology being moved out of beta: https://phabricator.wikimedia.org/T112127 ** Working on ElasticSearch 6 upgrade: https://phabricator.wikimedia.org/T183282 ** Working on running multiple Elastic instances on the same hardware: https://phabricator.wikimedia.org/T193654 ** Working on query parsing refactoring: https://phabricator.wikimedia.org/T185108 === Security === * Blocked by: * Blocking: * Updates:All Reviews are in progress by Security Analysts. ** === Services === * Blocked by: * Blocking: * Updates: ** === Site Reliability Engineering === * Blocked by: * Blocking: * Updates: ** == Wikidata == * Blocked by: ** Operations? Create a wmf production ready nginx image - https://phabricator.wikimedia.org/T209292 * Blocking: * Updates: ** Arbritray data access enabled on oldwikisource and any wiktionaries that didn't already have access == German Technical Wishlist == * Blocked by: * Blocking: * Updates: ** == Multi-Content Revisions == * Blocked by: * Blocking: * Updates: ** == SoS Meeting Bookkeeping == * Updates: **

1 0

MediaWiki-CodeSniffer 23.0.0 released
by Kunal Mehta 14 Nov '18

14 Nov '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello! MediaWiki-CodeSniffer 23.0.0 is now available for use in your MediaWiki extensions and other projects. This release features new sniffs and other bug fixes. Here's the changelog since 22.0.0: * Add comment why @private and @protected are okay (Umherirrender) * Add sniff to detect + for string concat (Umherirrender) * Add sniff to detect __METHOD__ in closures (Umherirrender) * Fix deprecation check for compounded licenses (Umherirrender) * Recognize MediaWikiTestCaseBase as test class (Aryeh Gregor) * Remove [optional] from types in @param (Umherirrender) * Update message to talk about "top level" instead of "file comment" (Thiemo Kreuz) * Upgrade squizlabs/php_codesniffer to 3.3.2 (Kunal Mehta) Thanks, - -- Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvr0ekACgkQUvyOe+23 /KLCUA/9GsLywwf0+P8K5619qSIJ4eXmyy0VGNvAeiLDpf1TqKtuVn+6jBF40RE0 3sU2LMUOjjMBjlEgJpXpmQciM606Ob3mG4XQrBnioQV7rIY8kG+gRwPdaEQxQGbj 8jATa59vzVNuLwZvCJ6Lsm0S1xuD5UYlPMjvmHtc0VM/bG9oeAT/FZBwAofrD88D W9bDcgo3jzQhv8smtYIhSzxLXrpPyccZyouwRxtYNlZHQg11pPm70qIPaJERxefi iyYyV22tEK6iewuS01oUJqoPg+t1mO/UMezdgxeOvCczZj1KwgpDaiB+JTX9/r6Z voEt/Zt67u1r90b2b7rNS30l309aZPRjgvGbFdFUe4uDwfmjXaZW4B2I0ZVXVCW1 A+2lN64wrRwQR74feO00nnl6bUC2IsjajwuOQ/pTJ6oXXda4hMT7+XX6u8fg1p9z xHv2jWtrCS/eGlMaRZ4PWqOEOHjaa0KOw/iKxaYnNAzkc1TMjHquDsv0DekBw9CP owkoKPWipsXKOg0r8oOinTx0+Hv5CvDDjSZPNftjoSng7GUtI4iU9SC2Uyk98ZW/ smsmWb1Ow0inV6Q3cGGctgvjDoyVhbcirmtXV6PlvanWHnMJziwRX6winz0F+YWG REo4UvdA69tSi+qzN64Il7YhFBFZuZpUSKsoV9uxWVjvPN93Dcc= =fN5s -----END PGP SIGNATURE-----

1 0

Extension test failures on PHP 7.1
by Kunal Mehta 14 Nov '18

14 Nov '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, In preparation for Wikimedia production switching to PHP 7.2, we need to get CI running using 7.2 (and for the rest of the MediaWiki world too!). But before we can do that, we'll need 7.1 to be passing first. The following extensions are currently failing tests on 7.1: * FileImporter: T206286 * Kartographer: T206293 * Wikibase: T205958 * WikibaseLexeme: T206100 * WikibaseMediaInfo: T206281 And one non-Wikimedia deployed extension: * MultiMaps: T206291 Thank you to James F, Matma Rex and Umherirrender for already fixing some other extensions that were failing. I'd like to make 7.1 tests voting by the end of the week, and would appreciate maintainers fixing their extensions before then. You can currently trigger 7.1 tests to verify fixes by commenting "check experimental" in Gerrit. Thanks, - -- Kunal / Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlu68zMACgkQUvyOe+23 /KJ6Aw//d/uVNoAjO3HfumaVwr0EqobZ3pHBOozl+pZAbMjeJRG4MkuoiRheAfYI L51iIDbYpTceqbsMsJD304E2d/nBjIXjVw5fdXn2qUSLt31lourUETl3akX12ueQ Gv1B3ZqMQqZ1e06agUg52dTnDJSPLSI3wCbRDQNV8fqC8xDrUe8N4Xzux7XE5zhT RltBHJUx+dm1uPyPC3nDa/tUTCXQHiYc5hn0M/2ZLv1+DZMV1tf/eQsLYdUhkm2A b/tUTwafUzlyXw6yJUhHDFxZX+jfds8ER3Hl8qPLaUH6UusaRz4YdoPMHEWsyUaf 3+3yp2xbvvADD4b3aNk2b1o0pykutciIaJjJA9gBXukxfvOutDxM5axEJlXLyovs FjCTMjNzrb4gv0eZ8MLRndtM4Rph+izTDmGtmTXsUyUESNN7Cul7ud6Y8zuRCCx5 Fzg1cWEn0bivECE43555SIldjgsDc/5Io5Gc/55lXNyqLzM3h6jW7gU3jyohAqfh DYT7Y7/fnqFQmqMiDztU+gOA4LMa2+Dj+EXBvIEYgUgdP3tQ0ro664HO+TeQWAqD YpIe/LzFwZnkuwwSZlgVYqCNqV1QCTqO36Gam/sJAyJ+TqtbjefjLFOiB9q6+l1F /bGy0XYB8msSavuljswr3uuPJx5V2n9T0/hXpYuBcphSkdzLH/E= =spUL -----END PGP SIGNATURE-----

2 3

Discovery Weekly Update for the week starting 2018-11-05
by Chris Koerner 13 Nov '18

13 Nov '18

Howdy, This is the weekly update from the Search Platform team for the week starting 2018-11-05 As always, feedback and questions welcome. == Discussions == === Search === * Gehel and Mathew worked on the separation of concerns for WDQS puppet module [0] * The team worked on calculating autocomplete examination probabilities from eventlogging data [1] * Mathew worked on fixing Type constraints in entry point for the WDQS puppet module [2] * David and Stas worked on creating a SearchQuery to be an immutable class holding all the information known after parsing the query [3] and it will ride the train the week of Nov 13th. [0] https://phabricator.wikimedia.org/T208394 [1] https://phabricator.wikimedia.org/T205348 [2] https://phabricator.wikimedia.org/T208393 [3] https://phabricator.wikimedia.org/T189880 ---- Subscribe to receive on-wiki (or opt-in email) notifications of the Discovery weekly update. https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly The archive of all past updates can be found on MediaWiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates Interested in getting involved? See tasks marked as "Easy" or "Volunteer needed" in Phabricator. [1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R [2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R Yours, Chris Koerner Community Relations Specialist Wikimedia Foundation

1 0

Re: [Wikitech-l] Change coming to how certain templates will appear on the mobile web
by Chris Koerner 13 Nov '18

13 Nov '18

>what does a few weeks mean exactly If things go well, sometime in the next two weeks. However, if we can't get it done (I think there's a few things to review for deployment) by the end of November we'll postpone until January as to avoid the English fundraiser. A small reminder, not to be too pedantic, but most templates described should be fine (famous last words). :) If you want to check out your favorite template on the mobile site, add "?minerva-issues=b" to see the new treatment. Thanks for the reminder for Tech News! Tabbing over to do that now. Yours, Chris Koerner Community Relations Specialist Wikimedia Foundation

1 0

Change coming to how certain templates will appear on the mobile web
by Chris Koerner 13 Nov '18

13 Nov '18

Hello, In a few weeks the Readers web team will be changing how some templates look on the mobile web site. We will make these templates more noticeable when viewing the article. We ask for your help in updating any templates that don't look correct. What kind of templates? Specifically templates that notify readers and contributors about issues with the content of an article – the text and information in the article. Examples like Template:Unreferenced or Template:More citations needed. [0] [1] Right now these notifications are hidden behind a link under the title of an article. We will format templates like these (mostly those that use Template:Ambox or message box templates in general) to show a short summary under the page title. You can tap on the "Learn more" link to get more information. [2] For template editors we have some recommendations on how to make templates that are mobile-friendly and also further documentation on our work so far. [3] [4] If you have questions about formatting templates for mobile, please leave a note on the project talk page or file a task in Phabricator and we will help you. [5] [6] ---- [0] https://www.wikidata.org/wiki/Q5962027 [1] https://www.wikidata.org/wiki/Q5619503 [2] https://meta.wikimedia.org/wiki/File:Page_issues_-_mobile_banner_example.jpg [3] https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles… [4] https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues [5] https://www.mediawiki.org/wiki/Talk:Reading/Web/Projects/Mobile_Page_Issues [6] https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Read… Yours, Chris Koerner Community Relations Specialist Wikimedia Foundation

2 1

RFC Discussion tomorrow: RfC: Session storage service interface
by Kate Chapman 13 Nov '18

13 Nov '18

Hi All, A reminder that TechCom is hosting an IRC meeting tomorrow (Wednesday 14 November) on RfC: Session storage service interface <https://phabricator.wikimedia.org/T206010> This RFC outlines an API for a new multi-master session storage service for use in multi-DC session management. The meeting is scheduled for Wednesday 14 November 2pm PST(22:00 UTC, 23:00 CET) in #wikimedia-office. If you haven't joined a #wikimedia-office meeting before more information can be found here <https://meta.wikimedia.org/wiki/IRC_office_hours#How_to_participate> More information regarding the TechCom RFC process is available here <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Processes#RFC_…> Thanks, -Kate -- Kate Chapman Senior Program Manager, Core Platform Wikimedia Foundation kchapman(a)wikimedia.org

2 1

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 November 2018