Re: [Wikitech-l] [Ops] mariadb 5.5 in production for english wikipedia
Hello Asher, Thanks so much for your hard work on supporting our MariaDB migration. I think that it's a big step for the MariaDB Foundation. — Patrick On Tue, Dec 11, 2012 at 4:17 PM, Peter Youngmeister p...@wikimedia.org wrote: Asher, This is awesome! Thank you for your hard, careful work and dedication in taking this huge first step in moving to MariaDB! --peter On Tue, Dec 11, 2012 at 4:10 PM, Asher Feldman afeld...@wikimedia.org wrote: Hi, This afternoon, I migrated one of the main production English Wikipedia slaves, db59, to MariaDB 5.5.28. We've previously been testing 5.5.27 on the primary research slave, and I've been testing the current build for the last few days on a slave in eqiad. All has looked good, and I spent the last few days adapting our monitoring and metrics collection tools to the new version, and building binary packages that meet our needs. A main gotcha in major version upgrades is performance regressions due to changes in query plans. I've seen no sign of this, and my initial assessment is that performance for our workload is on par with or slightly improved over the 5.1 facebook patchset. Taking the times of 100% of all queries over regular sample windows, the average query time across all enwiki slave queries is about 8% faster with MariaDB vs. our production build of 5.1-fb. Some queries types are 10-15% faster, some are 3% slower, and nothing looks aberrant beyond those bounds. Overall throughput as measured by qps has generally been improved by 2-10%. I wouldn't draw any conclusions from this data yet, more is needed to filter out noise, but it's positive. MariaDB has some nice performance improvements that our workload doesn't really hit (better query optimization and index usage during joins, much better sub query support) but there are also some things, such as full utilization of the primary key embedded on the right of every secondary index that we can take advantage of (and improve our schema around) once prod is fully upgraded, hopefully over the next 1-2 months. The main goal of migrating to MariaDB is not performance driven. More so, I think it's in WMF's and the open source communities interest to coalesce around the MariaDB Foundation as the best route to ensuring a truly open and well supported future for mysql derived database technology. Performance gains along the way are icing on the cake. -Asher ___ Ops mailing list o...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops ___ Ops mailing list o...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Antonio Pizzigati Prize for Software in the Public Interest
Well it exists now; http://en.wikipedia.org/wiki/Antonio_Pizzigati — Patrick On Mon, Dec 10, 2012 at 1:13 PM, Asher Feldman afeld...@wikimedia.org wrote: If anyone is interested, or knows of a worthy entrant, the application deadline for the 2013 Antonia Pizzigati prize, honoring open source software development in the public interest, has been extended to Friday, 14 December 2012. http://www.tides.org/impact/awards-prizes/pizzigati-prize/ The Antonio Pizzigati Prize for Software in the Public Interest annually awards a $10,000 cash grant to one individual who has created or led an effort to create an open source software product of significant value to the nonprofit sector and movements for social change. The Pizzigati Prize honors the brief life of Tony Pizzigati ( http://www.tides.org/impact/awards-prizes/pizzigati-prize/tony/ - he does not have a Wikipedia entry), an early advocate of open source computing. -Asher ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Really Fast Merges
There were 132 days for anybody to review and comment on the technical approach in the UID class. — Patrick On Wed, Dec 5, 2012 at 10:09 AM, Aaron Schulz aschulz4...@gmail.com wrote: Some notes (copied from private email): * It only creates the lock file the first time. * The functions with different bits are not just the same thing with more bits. Trying to abstract more just made it more confusing. * The point is to also have something with better properties than uniqid. Also I ran large for loops calling those functions and timed it on my laptop back when I was working on that and found it reasonable (if you needed to insert faster you'd probably have DB overload anyway). * hostid seems pretty common and is on the random wmf servers I tested a while back. If there is some optimization there for third parties that don't have it, of course it would be welcomed. At any rate, I changed the revert summary though Timo beat me to actually merging the revert. My main issue is the authorship breakage and the fact that the split of change wasn't +2'd by a different person. I was also later asked to add tests (36816), which should ideally would have been required in the first patch rather than as a second one; not a big deal but it's a plus to consolidating the changes after a revert. That said, the change was actually a class split off verbatim from https://gerrit.wikimedia.org/r/#/c/16696/ (which was pending for ages), so it's not like the change was in gerrit for a split-second and then merged. I think the process should have been better here though it's not a huge deal as it may seem at first glance. -- View this message in context: http://wikimedia.7.n6.nabble.com/Really-Fast-Merges-tp4990838p4990911.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Really Fast Merges
Tyler, It was uploaded originally in the following commit: https://gerrit.wikimedia.org/r/#/c/16696/ dated Jul 25, 2012 4:11 PM by Aaron Schulz. The only thing that I did was to break it off into a separate commit: https://gerrit.wikimedia.org/r/#/c/36801/ So, the point that I was attempting to make was that it in unaltered form was available for review for; 132 days or 4 months, 9 days. The mistake that I made was that I didn't use Forge Author and Forge Committer access control rights in Gerrit. As, well as NOT adding it to the auto loader initially. — Patrick On Wed, Dec 5, 2012 at 10:21 AM, Tyler Romeo tylerro...@gmail.com wrote: 132 days? It was uploaded onto Gerrit just recently. Many of the people here (including myself) only get notice of changes if it's discussed on the mailing list or if a change is uploaded to Gerrit. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Dec 5, 2012 at 1:13 PM, Patrick Reilly prei...@wikimedia.orgwrote: There were 132 days for anybody to review and comment on the technical approach in the UID class. — Patrick On Wed, Dec 5, 2012 at 10:09 AM, Aaron Schulz aschulz4...@gmail.com wrote: Some notes (copied from private email): * It only creates the lock file the first time. * The functions with different bits are not just the same thing with more bits. Trying to abstract more just made it more confusing. * The point is to also have something with better properties than uniqid. Also I ran large for loops calling those functions and timed it on my laptop back when I was working on that and found it reasonable (if you needed to insert faster you'd probably have DB overload anyway). * hostid seems pretty common and is on the random wmf servers I tested a while back. If there is some optimization there for third parties that don't have it, of course it would be welcomed. At any rate, I changed the revert summary though Timo beat me to actually merging the revert. My main issue is the authorship breakage and the fact that the split of change wasn't +2'd by a different person. I was also later asked to add tests (36816), which should ideally would have been required in the first patch rather than as a second one; not a big deal but it's a plus to consolidating the changes after a revert. That said, the change was actually a class split off verbatim from https://gerrit.wikimedia.org/r/#/c/16696/ (which was pending for ages), so it's not like the change was in gerrit for a split-second and then merged. I think the process should have been better here though it's not a huge deal as it may seem at first glance. -- View this message in context: http://wikimedia.7.n6.nabble.com/Really-Fast-Merges-tp4990838p4990911.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Refactor of mediawiki/extensions/ArticleFeedbackv5 backend
Fellow Wikimedia Developers, Matthias Mullie has been working hard to refactor the backend of mediawiki/extensions/ArticleFeedbackv5 to add proper sharding support. The original approach that he took was to rely on RDBStore that was first introduced in Change-Id: Ic1e38db3d325d52ded6d2596af2b6bd3e9b870fe https://gerrit.wikimedia.org/r/#/c/16696 by Aaron Schulz. Asher Feldman, Tim Starling and myself reviewed the new class RDBStore and determined that it wasn't really the best approach for our current technical architecture and database environment. Aaron Schulz had a lot of really good ideas included in RDBStore, but it just seemed like it wasn't a great fit right now. We decided collectively to abandon the RDBStore work permanently at this time. So, we're now left with the need to provide Matthias Mullie with some direction on what is the best solution for the ArticleFeedbackv5 refactor. One possible solution would be to create a new database cluster for this type of data. This cluster would be solely for data that is similar to Article Feedback's and that has the potential of being spammy in nature. The MediaWiki database abstraction layer could be used directly via a call to the wfGetDB() function to retrieve a Database object. A read limitation with this approach will be particularly evident when we require a complex join. We will need to eliminate any cross-shard joins. The reality is that Database Sharding is a very useful technology, but like other approaches, there are many factors to consider that ensure a successful implementation. Further, there are some limitations and Database Sharding will not work well for every type of application. So, to this point when we truly implement sharding in the future it will more than likely be benificial to focus on place in core mediawiki where it will have the greatest impact, such as the pagelinks and revision tables. — Patrick ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki + Vagrant
Done and done... https://github.com/wikimedia/wmf-vagrant Staff team has the following permissions push pull granted. — Patrick On Thu, Oct 18, 2012 at 12:52 PM, Tomasz Finc tf...@wikimedia.org wrote: Since were getting serious about it let's move it to the Wikimedia repot On Oct 17, 2012 11:39 PM, Erik Moeller e...@wikimedia.org wrote: On Wed, Oct 17, 2012 at 3:25 AM, Ori Livneh o...@wikimedia.org wrote: Ok, I made it work, I think git clone https://github.com/atdt/wmf-vagrant.git cd ./wmf-vagrant: git submodule update --init vagrant up And indeed, it works like magic. This is an awesome beginning, Ori - thanks so much for pulling this off. I really think this is a potentially great path to getting pre-built and optimized dev environments into people's hands. As for a permanent home, this isn't really operations and probably lots of folks should have merge rights on it, so perhaps a mediawiki/vagrant repo with a broad permission set would make sense? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki + Vagrant
That's awesome! Will it be recorded tonight? — Patrick On Thu, Oct 18, 2012 at 2:28 PM, Ori Livneh o...@wikimedia.org wrote: Woot! Thanks guys. I'll use my five-minute slot at the meet up tonight to demo its use. -- Ori Livneh o...@wikimedia.org On Thursday, October 18, 2012 at 10:05 AM, Patrick Reilly wrote: Done and done... https://github.com/wikimedia/wmf-vagrant Staff team has the following permissions push pull granted. — Patrick On Thu, Oct 18, 2012 at 12:52 PM, Tomasz Finc tf...@wikimedia.org(mailto: tf...@wikimedia.org) wrote: Since were getting serious about it let's move it to the Wikimedia repot On Oct 17, 2012 11:39 PM, Erik Moeller e...@wikimedia.org (mailto: e...@wikimedia.org) wrote: On Wed, Oct 17, 2012 at 3:25 AM, Ori Livneh o...@wikimedia.org(mailto: o...@wikimedia.org) wrote: Ok, I made it work, I think git clone https://github.com/atdt/wmf-vagrant.git cd ./wmf-vagrant: git submodule update --init vagrant up And indeed, it works like magic. This is an awesome beginning, Ori - thanks so much for pulling this off. I really think this is a potentially great path to getting pre-built and optimized dev environments into people's hands. As for a permanent home, this isn't really operations and probably lots of folks should have merge rights on it, so perhaps a mediawiki/vagrant repo with a broad permission set would make sense? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto: Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Welcome Michelle Grover as QA to the Mobile Team!
Welcome! — Patrick On Tue, Oct 9, 2012 at 3:19 PM, Amir E. Aharoni aahar...@wikimedia.orgwrote: Welcome! Prepare to a lot of weird bugs that affect weird languages :) -- Amir Elisha Aharoni ። אָמִיר אֱלִישָׁע אַהֲרוֹנִי Localization developer ። מְפַתֵּחַ תְּמִיכָה רַב־לְשׁוֹנִית Wikimedia Foundation ። קֶרֶן וִיקִימֶדְיָה 2012/10/9 Tomasz Finc tf...@wikimedia.org: Greetings all, I am pleased to announce that Michelle Grover joins WMF this week as a Mobile QA contractor. Michelle has worked as a Java Developer, Software Developer in Test, Release Engineer for Adobe, and Mobile QA Automation Lead for Crowdfusion (They developed The Daily, TMZ, Telepictures mobile applications). She's worked closely with agile teams (SCRUM and XP) over the past 7 + years, Implemented Kanban and setup and configured CI using Hudson,Team CIty and Cruise Control. She's been married 17 years and has a 6 year old son. Currently lives in Monument, CO and has spent a lot of time up in the mountains. Michelle will help both the community and mobile team build out a sound process for testing both the mobile web and our apps. The team would like to welcome her and wish her success. --tomasz ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GC cache entry
Time to time, we receive a strange warning message
in fenari:/home/wikipedia/log/syslog/apache.log
Oct 3 01:01:03 10.0.11.59 apache2[20535]: PHP Warning: * require() [a
href='function.require'function.require/a]: GC cache entry
'/usr/local/apache/common-local/wmf-config/ExtensionMessages-1.20wmf12.php'
(dev=2049 ino=10248005) was on gc-list for 601 seconds in
/usr/local/apache/common-local/php-1.20wmf12/includes/AutoLoader.php* on
line 1150
Definitely this issue comes from *APC*, source code from package
apc-3.1.6-r1.
When item is inserted into user cache or file cache, this function is
called.
static void process_pending_removals(apc_cache_t* cache TSRMLS_DC)
{
slot_t** slot;
time_t now;
/* This function scans the list of removed cache entries and deletes any
* entry whose reference count is zero (indicating that it is no longer
* being executed) or that has been on the pending list for more than
* cache-gc_ttl seconds (we issue a warning in the latter case).
*/
if (!cache-header-deleted_list)
return;
slot = cache-header-deleted_list;
now = time(0);
while (*slot != NULL) {
int gc_sec = cache-gc_ttl ? (now - (*slot)-deletion_time) : 0;
if ((*slot)-value-ref_count = 0 || gc_sec cache-gc_ttl) {
slot_t* dead = *slot;
if (dead-value-ref_count 0) {
switch(dead-value-type) {
case APC_CACHE_ENTRY_FILE:
apc_warning(GC cache entry '%s' (dev=%d ino=%d)
was on gc-list for %d seconds TSRMLS_CC,
dead-value-data.file.filename,
dead-key.data.file.device, dead-key.data.file.inode, gc_sec);
break;
case APC_CACHE_ENTRY_USER:
apc_warning(GC cache entry '%s'was on gc-list for
%d seconds TSRMLS_CC, dead-value-data.user.info, gc_sec);
break;
}
}
*slot = dead-next;
free_slot(dead TSRMLS_CC);
}
else {
slot = (*slot)-next;
}
}
}
From APC configuration (
http://us.php.net/manual/en/apc.configuration.php#ini.apc.gc-ttl )
*apc.gc_ttl integer*
The number of seconds that a cache entry may remain on the
garbage-collection list. This value provides a fail-safe in the event that
a server process dies while executing a cached source file; if that source
file is modified, the memory allocated for the old version will not be
reclaimed until this TTL reached. Set to zero to disable this feature.
We get messages GC cache entry '%s' (dev=%d ino=%d) was on gc-list for %d
seconds or GC cache entry '%s'was on gc-list for %d seconds in this
condition:
(gc_sec cache-gc_ttl) (dead-value-ref_count 0)
First condition means, item was deleted later then apc.gc_ttl seconds ago
and its still in garbage collector list.
Seconds condition means, item is still referenced.
e.g., when a process unexpectedly died, reference is not decreased. First
apc.ttl seconds is active in APC cache, then is deleted (there isn't next
hit on this item). Now item is on garbage collector list (GC) and
apc.gc_ttl timeout is running.
When apc.gc_ttl is less then (now - item_deletion_time), warning is written
and item is finally completely flushed.
So what should we do?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Security alert: PHP 5.4.3 windows version upload exploit
Got to love code like this: http://www.exploit-db.com/exploits/18861/ — Patrick On Mon, May 21, 2012 at 1:21 PM, Thomas Gries m...@tgries.de wrote: ** Keine Antwort erforderlich ** no reply needed ** FYI: I just received the following information http://www.heise.de/newsticker/meldung/Ungepatche-Luecke-in-aktueller-PHP-Version-1580790.html (German) https://isc.sans.edu/diary.html?storyid=13255 Clarifications/Updates to the original diary: - This is NOT remote exploitable. An exploit would require the attacker to upload PHP code to the server, at which point, the attacker could just use PHP to run shell commands via exec. - only the windows version is vulnerable There is a remote exploit in the wild for PHP 5.4.3 in Windows, which takes advantage of a vulnerability in the com_print_typeinfo http://php.net/manual/en/function.com-print-typeinfo.php function. The php engine needs to execute the malicious code, which can include any shellcode like the the ones that bind a shell to a port. ** Keine Antwort erforderlich ** no reply needed ** ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on PHP namespaces?
On Thu, May 17, 2012 at 10:11 AM, Terry Chay tc...@wikimedia.org wrote: Hmm maybe technically. But the way namespaces are implemented in PHP 5.3 is very simple (that's part of the reason they chose the forward slash separator). I think you mean the *backslash* (\) character. HipHop can be easily upgraded to support it… if it hasn't been done already. I guess the only sure way is to compile some test scripts in HH. There might be some edge cases they missed. :-) On May 17, 2012, at 9:59 AM, Platonides wrote: Wouldn't that make it incompatible with hiphop? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stance on PHP namespaces?
On Wed, May 16, 2012 at 4:03 PM, Daniel Friesen li...@nadir-seen-fire.comwrote: On Wed, 16 May 2012 15:52:44 -0700, Max Semenik maxsem.w...@gmail.com wrote: On 17.05.2012, 2:36 Jeroen wrote: Hey, I am not aware of any guidelines regarding the usage of PHP namespaces in MediaWiki and di not find any on MediaWiki.org. Not surprising since 1.20 is the first release in which we can actually use it. So I'm curious on peoples thoughts on how to use this new features, if at all, in core and in extensions. As far as I get it, we cannot simply put it into core without breaking compat all over he place, but could gradually introduce it for new components. For new extensions it's a lot easier of course, which happens to be the use case I'm currently facing, and wondering what to best do. MediaWiki\ExtensionName seems like a reasonable NS for extension classes. Frankly, the namespace syntax in PHP is so atrocitous that I would like to never see namespaces in out code:P Seriously though, I think we should start slowly, maybe not including namespaces in 1.20 and then tread carefully - some extension devs might want to be compatible with older MW versions that support PHP 5.2. I don't think we should use namespaces at all unless there is a good reason for it. The only case I think we should allow namespaces in is within a MediaWiki component with a lot of small classes related to the component. Well namespaces can provide for better organization, readability and dependency tracking among other things. So, it's probably worth investigating this a bit more. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia MediaWiki configuration files are now in a public version control system
We've got passwords in the repo. https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/CommonSettings.php;h=ad7c776905e6074a5f415339fdba146ae3f5788a;hb=d4c704fe499bdebf36877c1f3b8cee4a8e9014f7#l2260 — Patrick On Wed, May 9, 2012 at 4:33 PM, Chad innocentkil...@gmail.com wrote: On Wed, May 9, 2012 at 7:17 PM, K. Peachey p858sn...@gmail.com wrote: On Thu, May 10, 2012 at 8:14 AM, Sam Reed re...@wikimedia.org wrote: No history of these files have been imported. Any reason for this? Some of them have had private info in them in the past (usually by accident). -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia MediaWiki configuration files are now in a public version control system
It is fixed now. — Patrick On Wed, May 9, 2012 at 4:47 PM, K. Peachey p858sn...@gmail.com wrote: On Thu, May 10, 2012 at 9:44 AM, Patrick Reilly prei...@wikimedia.org wrote: We've got passwords in the repo. https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/CommonSettings.php;h=ad7c776905e6074a5f415339fdba146ae3f5788a;hb=d4c704fe499bdebf36877c1f3b8cee4a8e9014f7#l2260 Use PrivateSettings.php (or whatever its called for that), and read the headers next time # WARNING: This file is publically viewable on the web. Do not put private data here. CommonSettings.php has been readable for a long time. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Commits IDs, change IDs, legacy change IDs, oh my!
On Tue, Apr 24, 2012 at 12:00 PM, Erik Moeller e...@wikimedia.org wrote: Hi all, can we agree on how we want to identify changes - when deploying code - when merging follow-ups - when commenting on bugzilla? Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to see an example of a mix between Gerrit legacy change IDs (integers, as URLs) and commit IDs. For commit messages the recommendation is to use change IDs (as hashes). So this means constant back and forth between different ID types, which is confusing to developers and users. I'm personally not a fan of the Gerrit change-IDs in plain form, because I can't use them with commands like 'git log' or 'git show' without grepping through commit messages. Well, you can always do something like: ssh -p 29418 gerrit.wikimedia.org gerrit query change:I1744438cbee58f149e1105e7856d00343f04d55a status:merged --patch-sets --format=TEXT limit:1 | grep 'revision:' and get output like: revision: 782ab823d7ab672ef5e849631a47cdf8eae49410 They tie us pretty heavily to Gerrit as the gateway to all info as opposed to using Git's native lookup capabilities. One proposal: - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to un-merged commits - Commit SHA-1s for deployment log entries and follow-ups to merged commits Rationale: - A Gerrit URL helps others skip past the fragile Gerrit search and go right to the relevant change. This gives them access to change-ID, SHA-1s, and anything else they may need. It's appropriate when you're likely to need to go into the full context of a change. - A SHA-1 gives you instant visibility to the code in your repo without having to use Gerrit as an intermediary, or having to do slow searches of your commit messages for a change-ID. Just do 'git show'. Git intelligently parses abbreviated hashes as well. It's appropriate when you're past the point of code review and are just referring to a change that's sitting somewhere in the repo. This is just one possible approach, and I'm sure this is something we can argue about endlessly. I don't much care what pattern we adopt, as long as it's reasonably consistent, especially for deployment log entries and follow-ups. Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Run batch actions on gerrit changesets from the command line with DippyBird
Awesome work Arthur! — Patrick On Fri, Apr 13, 2012 at 5:32 PM, Arthur Richards aricha...@wikimedia.org wrote: Just spent some time updating dippy-bird. Now using 'gerrit review' (thanks Chad) and now supports code review, abandon, submit, and restore operations on changesets in gerrit. This has already proved super handy for me when I've needed to do do a bulk-abandon on changesets. Take it for a spin, let me know what you think, make any changes you see fit! http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/gerrit-dippybird/dippy-bird.php On Sat, Mar 31, 2012 at 1:51 AM, Chad innocentkil...@gmail.com wrote: Minor nitpick: 'gerrit approve' is deprecated in favor of 'gerrit review' -Chad On Mar 30, 2012 7:50 PM, Arthur Richards aricha...@wikimedia.org wrote: I whipped together a php script this afternoon that allows you to make arbitrary queries for Gerrit change sets, and then perform bulk actions on the resulting change sets from the command line. Currently it only supports doing a bulk 'submit' (with approve +2 and verify +1), but it won't take much to add in other things (like abandon, verify, approve, etc). Take a look and feel free to comment/make changes: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/gerrit-dippybird/dippy-bird.php -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Hackathon Berlin 2012
I'd run it. — Patrick On Thu, Mar 29, 2012 at 2:05 PM, Chad innocentkil...@gmail.com wrote: On Thu, Mar 29, 2012 at 4:57 PM, Thomas Gries m...@tgries.de wrote: Suggestion: git workshop and tutorial @ Hackathon Berlin 2012 Anyone volunteering to run it? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit bots notification
Yeah, can we modify it to send MobileFrontend notifications to #wikimedia-mobile. — Patrick On Tue, Mar 27, 2012 at 11:28 AM, Antoine Musso hashar+...@free.fr wrote: Hello, Whenever an action is made in Gerrit, a notification is sent to some IRC channels. Previously we had to map each project to an IRC channel fall backing to #mediawiki. I have enhanced the python script to support wildcard when filtering on Gerrit project name. Leslie Carr has deployed the changes some minutes ago, and now: projects from: - analytics and integrations are sent to #wikimedia-dev - operations are sent to #wikimedia-operations - labs to #wikimedia-labs - mediawiki and mediawiki extensions to #mediawiki Default is still #mediawiki If someone need more specific rules, you should tweak the filenames dictionary in templates/gerrit/hookconfig.py.erb . As an example, we might want to send MobileFrontend notifications to #wikimedia-mobile . -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WURFL licensing concerns and Git migration
I can remove it. — Patrick On Mar 20, 2012, at 10:53 PM, Erik Moeller e...@wikimedia.org wrote: On Tue, Mar 20, 2012 at 10:37 PM, Q overlo...@gmail.com wrote: ScientiaMobile basically took an open data repository and closed it, the complete opposite of what the WMF is trying to do. I'd strongly suggest looking for real Open solutions like OpenDDR/DeviceMap And apparently they've been trying to take down legitimate copies, too: http://openddr.org/takedown.html Yikes, that's evil. To the extent we're relying on it today, we should move off it ASAP. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20
The key features of PHP 5.3.0 include: Support for namespaces Late static binding Lambda Functions and Closures Syntax additions: NOWDOC, ternary short cut ?: and jump label (limited goto), __callStatic() Under the hood performance improvements Optional garbage collection for cyclic references More consistent float rounding... Deprecation notices are now handled via E_DEPRECATED (part of E_ALL) instead of the E_STRICT error level Several enhancements to enable more flexiblity in php.ini (and ini parsing in general) On Feb 24, 2012 2:35 AM, Arthur Richards aricha...@wikimedia.org wrote: The correct answer is I'm sorry this is inconvenient, ask your hosting provider or find a better one. I completely agree. Being able to use features like namespaces and late static binding would be a huge win. I'm definitely in favor of bumping the minimum PHP version to 5.3.x. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] getting started with volunteer mediawiki development
This went really well in Pine. -- Patrick On Feb 16, 2012 11:25 PM, Arthur Richards aricha...@wikimedia.org wrote: For the hackathon in Pune, I prepared an 'intro to hacking mediawiki' tutorial for novices. There are a few mistakes in the tutorial, feel free to adjust as needed: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/Extension_Writing_Tutorial Also, Sumana prepared a 'How to become a Mediawiki Hacker' workshop, outlined here: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/Workshop Arthur On Tue, Feb 14, 2012 at 2:44 PM, Ryan Lane rlan...@gmail.com wrote: I've given a few talks on this at random places. Slides are up on wikitech in PDF form, and on my blog in ODF format: http://wikitech.wikimedia.org/index.php?title=File:Ryan_Lane_-_How_to_be_a_part_of_the_MediaWiki_developer_community.pdfpage=1 http://ryandlane.com/blog/wp-content/uploads/2010/11/How-to-be-a-part-of-the-MediaWiki-developer-community.odp The ODF version has full notes, if you switch to notes view. - Ryan On Tue, Feb 14, 2012 at 11:03 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Hey guys, I'm going to be giving a presentation next month at the University of Chile to their incoming freshman CS students on how to get started with volunteer open source software development and specifically MediaWiki development. If anyone has material that would be useful for such a presentation (slides, charts, documentation, funny pictures, etc.), please let me know. Things I'm hoping to incorporate already: http://openhatch.org/ (lots of good newbie resources) http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker (intro documentation) http://www.mediawiki.org/wiki/Annoying_little_bugs (good places to start) Sumana (human interface) Thanks. Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] getting started with volunteer mediawiki development
Darn autocorrect... meant Pune. On Feb 16, 2012 11:27 PM, Patrick Reilly prei...@wikimedia.org wrote: This went really well in Pine. -- Patrick On Feb 16, 2012 11:25 PM, Arthur Richards aricha...@wikimedia.org wrote: For the hackathon in Pune, I prepared an 'intro to hacking mediawiki' tutorial for novices. There are a few mistakes in the tutorial, feel free to adjust as needed: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/Extension_Writing_Tutorial Also, Sumana prepared a 'How to become a Mediawiki Hacker' workshop, outlined here: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker/Workshop Arthur On Tue, Feb 14, 2012 at 2:44 PM, Ryan Lane rlan...@gmail.com wrote: I've given a few talks on this at random places. Slides are up on wikitech in PDF form, and on my blog in ODF format: http://wikitech.wikimedia.org/index.php?title=File:Ryan_Lane_-_How_to_be_a_part_of_the_MediaWiki_developer_community.pdfpage=1 http://ryandlane.com/blog/wp-content/uploads/2010/11/How-to-be-a-part-of-the-MediaWiki-developer-community.odp The ODF version has full notes, if you switch to notes view. - Ryan On Tue, Feb 14, 2012 at 11:03 PM, Ryan Kaldari rkald...@wikimedia.org wrote: Hey guys, I'm going to be giving a presentation next month at the University of Chile to their incoming freshman CS students on how to get started with volunteer open source software development and specifically MediaWiki development. If anyone has material that would be useful for such a presentation (slides, charts, documentation, funny pictures, etc.), please let me know. Things I'm hoping to incorporate already: http://openhatch.org/ (lots of good newbie resources) http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker (intro documentation) http://www.mediawiki.org/wiki/Annoying_little_bugs (good places to start) Sumana (human interface) Thanks. Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC Complete Rewrite of Mobile Frontend Rename MobileFrontend2
John DuHart has embarked on a complete rewrite of the current Mobile Frontend extension, and has decided to name it 'MobileFrontend2'. While we would prefer it if we could work cooperatively to resolve the existing open issues in the current MobileFrontend extension and maintain continuity. It's understandable why John would prefer to undertake his complete rewrite. (See Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940 ) However, we feel that naming the rewrite 'MobileFrontend2' is problematic as users have already started to confuse it with the current extension. One thought was to name it to MobileSkin, but it appears that this extension already exists and we quickly reverted that rename attempt. We're curious to hear the rest of the engineering community's perspective and try to gain some consensus as to how best to proceed. — The Mobile Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No autodetection in Mobile Frontend extension
The following link outlines a way to add the simple device detection to the current Mobile Frontend extension. https://raw.github.com/gist/1590648/86abdf93a99876c609862b28f8dae1b488bded03/MobileFrontend.php I'll work on a more complete solution that utilizes WURFL and post that later. — Patrick On Mon, Jan 9, 2012 at 11:21 PM, Daniel Friesen li...@nadir-seen-fire.com wrote: I've heard of some sites using a pattern like /m/ for their mobile site. We can probably support that option as well. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On Mon, 09 Jan 2012 21:00:45 -0800, User:Matthewrbowker matthewrbowker.w...@gmail.com wrote: I, for one, would love to use Mobile Frontend to add mobile functionality on a wiki I run (at least to view, is it possible to add editing?). However, I don't have the option of defining a separate mobile sub-subdomain (my wiki is already on a subdomain) because of limitations set by my web host. Matthew Bowker On Jan 9, 2012, at 12:03, Brion Vibber br...@pobox.com wrote: Quick questions: * Does anybody actually want to use MobileFrontend to implement a feature-phone gateway on other sites? If so, it may be worth doing some of that cleanup to make things more portable. Note that I'd also love to kill the m. stuff as it's problematic in a number of ways, so I wouldn't worry too much about stuff related to mobile-specific URLs. * Do people intend primarily to make the wiki's user interface more friendly to modern smartphones, without caring about feature phones? If so, then moving to the next generation beyond our current MobileFrontend is probably a better use of energy. MobileFrontend's architecture is keyed on basically being like a proxy, so it can produce output tuned to phones with very limited capabilities without the rest of MediaWiki needing to worry about how those things work. This isn't really what we want for smartphones and tablets in the future; they should instead get the same interface and capabilities as the desktop provides, but the interface should tune itself for small or large screens, touch-centric or mouse-centric layouts. In the future this won't involve the MobileFrontend extension at all, it'll just be in our core CSS JS code's behavior. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No autodetection in Mobile Frontend extension
Do you have memcached installed?
— Patrick
On Sun, Jan 8, 2012 at 1:21 AM, Quim Gil quim...@gmail.com wrote:
The Mobile Frontend extension brought my site down after using it as
is. I have got +50Mb of error logs but basically it looks like the
Apache ACP collapsed.
I guess this problem has the same root as the lack of autodetection in
my faulty implmentation? Below you have excerpts from the logs just in
case they are useful.
Extracted from logs/php/www-error.log:
[07-Jan-2012 17:02:51] PHP Notice: Undefined index: host in
/path/to/file/extensions/MobileFrontend/MobileFrontend.php on line 622
[07-Jan-2012 17:02:51] PHP Stack trace:
...
[07-Jan-2012 17:02:51] PHP 9.
ExtMobileFrontend-beforePageDisplayHTML() /includes/Hooks.php:0
[07-Jan-2012 17:02:51] PHP 10. ExtMobileFrontend-getMsg()
/extensions/MobileFrontend/MobileFrontend.php:547
[07-Jan-2012 17:02:51] PHP 11. ExtMobileFrontend-getRelativeURL()
/extensions/MobileFrontend/MobileFrontend.php:342
...
[07-Jan-2012 18:21:02] PHP Warning: apc_store(): Unable to allocate
memory for pool. in includes/objectcache/APCBagOStuff.php on line 20
[07-Jan-2012 18:21:02] PHP Stack trace:
...
[07-Jan-2012 18:21:02] PHP 9.
ExtMobileFrontend-beforePageDisplayHTML() includes/Hooks.php:0
[07-Jan-2012 18:21:02] PHP 10. WURFL_WURFLManagerFactory-create()
/extensions/MobileFrontend/MobileFrontend.php:375
[07-Jan-2012 18:21:02] PHP 11. WURFL_WURFLManagerFactory-init()
/extensions/MobileFrontend/library/WURFL/WURFLManagerFactory.php:66
[07-Jan-2012 18:21:02] PHP 12.
WURFL_WURFLManagerFactory-deviceRepository()
/extensions/MobileFrontend/library/WURFL/WURFLManagerFactory.php:127
[07-Jan-2012 18:21:02] PHP 13. WURFL_DeviceRepositoryBuilder-build()
/extensions/MobileFrontend/library/WURFL/WURFLManagerFactory.php:164
[07-Jan-2012 18:21:02] PHP 14.
WURFL_DeviceRepositoryBuilder-buildRepository()
/extensions/MobileFrontend/library/WURFL/DeviceRepositoryBuilder.php:86
[07-Jan-2012 18:21:02] PHP 15.
WURFL_DeviceRepositoryBuilder-process()
/extensions/MobileFrontend/library/WURFL/DeviceRepositoryBuilder.php:107
[07-Jan-2012 18:21:02] PHP 16.
WURFL_DeviceRepositoryBuilder-classifyAndPersistDevice()
extensions/MobileFrontend/library/WURFL/DeviceRepositoryBuilder.php:188
[07-Jan-2012 18:21:02] PHP 17. WURFL_Storage_Mwmemcache-save()
/extensions/MobileFrontend/library/WURFL/DeviceRepositoryBuilder.php:211
[07-Jan-2012 18:21:02] PHP 18. APCBagOStuff-set()
/extensions/MobileFrontend/library/WURFL/Storage/Mwmemcache.php:41
[07-Jan-2012 18:21:02] PHP 19. apc_store()
includes/objectcache/APCBagOStuff.php:20
...
[08-Jan-2012 01:45:08] PHP Warning: require(): c cache entry
'/includes/parser/CoreParserFunctions.php' (dev=2097211 ino=1668) was
on gc-list for 2643 seconds in
/srv/data/web/vhosts/espiral.org/htdocs/includes/AutoLoader.php on
line 918
[08-Jan-2012 01:45:08] PHP Stack trace:
[08-Jan-2012 01:45:08] PHP 1. {main}() index.php:0
[08-Jan-2012 01:45:08] PHP 2. MediaWiki-run() index.php:57
[08-Jan-2012 01:45:08] PHP 3. MediaWiki-main() includes/Wiki.php:533
[08-Jan-2012 01:45:08] PHP 4. MediaWiki-performRequest()
includes/Wiki.php:626
[08-Jan-2012 01:45:08] PHP 5. MediaWiki-initializeArticle()
/includes/Wiki.php:230
[08-Jan-2012 01:45:08] PHP 6. Article::newFromTitle() includes/Wiki.php:318
[08-Jan-2012 01:45:08] PHP 7. AutoLoader::autoload()
includes/AutoLoader.php:0
From logs/php/fpm.log:
[07-Jan-2012 18:22:56] WARNING: [pool www] child 2872, script
'index.php' (request: GET /index.php) execution timed out
(121.002992 sec), terminating
[07-Jan-2012 18:22:56] WARNING: [pool www] child 2872 exited on signal
15 (SIGTERM) after 37757.970325 seconds from start
From logs/apache/error.log
[Sat Jan 07 18:22:56.648588 2012] [:error] [pid 4056:tid
3814288475904] (104)Connection reset by peer: [client
89.246.16.155:59643] FastCGI: failed to read from backend server
Without ssh access to this server, now I can't restart ACP or Apache.
I have contact the ISP but as usual these things always happen on a
weekend. No big deal, I'm still building the site.
--
Quim
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No autodetection in Mobile Frontend extension
You need to set an xdevice header. We do that in our varnish caching layer. You can modify the code to set it based on WURFL detection. I'll send you the modifications on Monday... if that is okay. -- Patrick On Jan 7, 2012, at 1:18 AM, Quim Gil quim...@gmail.com wrote: Hi, I have installed the Mobile Frontend extension in my pet project at http://espiral.org I only get to the mobile view manually, through the link at the footer. Autodetection of mobile browsers doesn't seem to work or I have done / missed something in my installation. I have got feedback from a bunch of users with a bunch of devices, nobody got the mobile view by default and all of them get it when visiting http://en.wikipedia.org Something that looks different in my installation compared to Wikipedia's is the lack of a redirect to a .m. URL. I'm actually a bit confused about this. It is mentioned briefly at http://www.mediawiki.org/wiki/Extension:MobileFrontend but it is not clear to me whether this is something supposed to work automagically when installing the extension or whether there is something I need to do with the WURFL database, the LocalSettings.php, the web server... Other than this the extension works great presenting the mobile view of pages. Thank you very much for your work! -- Quim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] No autodetection in Mobile Frontend extension
On Jan 7, 2012, at 2:21 AM, Daniel Friesen li...@nadir-seen-fire.com wrote: On Sat, 07 Jan 2012 01:18:20 -0800, Quim Gil quim...@gmail.com wrote: Hi, I have installed the Mobile Frontend extension in my pet project at http://espiral.org I only get to the mobile view manually, through the link at the footer. Autodetection of mobile browsers doesn't seem to work or I have done / missed something in my installation. I have got feedback from a bunch of users with a bunch of devices, nobody got the mobile view by default and all of them get it when visiting http://en.wikipedia.org Something that looks different in my installation compared to Wikipedia's is the lack of a redirect to a .m. URL. I'm actually a bit confused about this. It is mentioned briefly at http://www.mediawiki.org/wiki/Extension:MobileFrontend but it is not clear to me whether this is something supposed to work automagically when installing the extension or whether there is something I need to do with the WURFL database, the LocalSettings.php, the web server... Other than this the extension works great presenting the mobile view of pages. Thank you very much for your work! I've been examining the MobileFrontend code myself since I too wanted to use it on a wiki. The MobileFrontend code is written 'very' WMF centric and uses a large number of hacks (which imho aren't acceptable of an extension purporting to be usable outside of WMF). It's a long way away from being usable on a normal wiki. How so? What would you change? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please Welcome Yuvaraj Pandian Max Semink
Welcome Yuvi and Max! — Patrick On Mon, Dec 19, 2011 at 10:31 AM, Arthur Richards aricha...@wikimedia.orgwrote: Congrats to you both! It's great to have you on board :D On Mon, Dec 19, 2011 at 10:15 AM, Alolita Sharma asha...@wikimedia.org wrote: Awesome to see Yuvi and Max join the engineering team! Welcome! -Alolita On Mon, Dec 19, 2011 at 10:10 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2011/12/19 Tomasz Finc tf...@wikimedia.org: Greetings all, The Mobile and Special Projects department is pleased to announce the addition of two new contractors to the team: Yuvaraj Pandian and Max Seminik. நல்வரவு / добро пожаловать! -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Alolita Sharma Features Engineering Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Final mobile switch-over
On Mon, Nov 21, 2011 at 2:33 PM, Strainu strain...@gmail.com wrote: 2011/11/15 Philip Chang pch...@wikimedia.org: TO: All Wikimedia Project Administrators As a follow-up to this original blog post about the new mobile site: http://blog.wikimedia.org/2011/09/14/new-mobile-site-launched-on-wikipedia-soon-for-sister-wikis-too/ Please note that the conversion to the new Mobile Frontend extension will be completed in the week of November 28. This means that by default any user of a mobile device will see the mobile interface rather then the desktop version. Users will no longer have to add the extra .m by hand. This also means any home pages not yet designed for mobile viewing will appear with a search bar only - unless you create a home page in the next three weeks, which is very easy to do! Instructions for creating a home page are here: http://meta.wikimedia.org/wiki/Mobile_Projects/Mobile_Gateway#Mobile_homepage Please forward this email as necessary. As always, the mobile-l and mobile-feedback-l mailing lists are available. There will be many more announcements in the coming months on mobile-l, and always feel free to send comments to mobile-feedback-l. Thank you. Phil Thanks for the heads-up Philip. I tried to apply your advice to ro.wp [1] and it worked only partially: the article of the day and the news sections appear, but not the did you know, on this day and the custom comunitate sections. Why is that? Did you add the title attribute? Another question is how do I know in a template that the mobile skin is active? Currently you don't as it occurs after the template is parsed. We have customized versions for the Quality Article and On this Day sections that are much better adapted for the mobile screens. Also, why do the standard sections begin with mp and the custom ones with mf? The custom ones use mf as an abbreviation of Mobile Frontend the name of the extension that renders mobile content. Thanks, Strainu [1] https://ro.wikipedia.org/w/index.php?title=Pagina_principal%C4%83action=historysubmitdiff=5856180oldid=5437667 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Coding challenge about to land. :)
Well, for the record the overall coding challenge project is being coordinated by Greg DeKoenigsberg, formerly Senior Community Architect at Red Hat. ;) — Patrick On Fri, Oct 21, 2011 at 4:02 PM, Platonides platoni...@gmail.com wrote: Greg DeKoenigsberg wrote: No. You'd sound like an ideal tester hitting a use case we didn't even consider. Will look into it. --g I don't want to sound harsh, Greg but... who are you? It seems it's the first time you post here, yet your email is written as if you were in charge of this. PS: I've heard ED tastes delicious :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phonegap and Wikimedia mobile apps
That would be a really nice addition to the official application in the future. We should definitely continue to talk about this and try to figure out the optimal approach. Also, once the PhoneGap based Android application is developed it should be easy to fork and experiment with the various approaches described below. — Patrick On Sat, Aug 27, 2011 at 10:17 PM, Christian Pühringer c...@gmx.at wrote: Hi, It would be really nice if offline (=zim) support was integrated in the official wikipedia app: The user could switch between online access and offline reading. If I understand Tomasz correctly, it is planned to implement the wikipedia app with phonegap, so having zim support for phonegap would allow integration of offline support into the app. Therefore I think its a good idea to implement zim support for phone gap. Regarding the technical details there a basically to ways to implement zim support in phonegap: - Using phonegap API. Theoretically device independent, but questionable whether actually working with sufficient performance on all target platforms. - As plugin: Implemented as a native component, with bindings to phonegap. I'd prefer the plugin approach. The additional effort of implementing the zimlib plugin for different platforms is not that high. The zimlib (and liblzma) is already available for C++ (STL): Symbian[1], Meego[2], Android (with NDK, cleaner is to use Java), iPhone (untested, may have some issues (see [5]), alternative would be to port to objective-C) and probably Bada Java (less mature than C++ implementation) : Android, Blackberry and other J2ME [3] (not sure whether possible on J2ME, but this is even more true for phonegap API approach) Porting needs only to be done to: C#: Windows Mobile Other: ? In addition the plugins for the platforms need to be written but this shouldn't be a too high effort. The zimlib is already pretty stable, so the maintenance effort for the ports should not be too bad. An additional benefit of the plugin-approach is that the ported zimlibs plugins can also be used for native apps. (Besides having the plain zimlib, the plugin projects can be used as a starting point for new projects). For the phonegap API approach zimlib must be ported to java script. As mentioned before I doubt that the javascript zimlib would work with sufficient performance on all (if any) . devices. See for example [4] Best regards, Christian [1] Neither File (required for phonegap API approach) nor plugins officially supported in phonegap. However, should be pretty easy to add. (Either in official (=WRT) phonegap, or in QT port. Probably better in QT port). [2] Not supported by phonegap. However, should be possible to use QT phonegap port. [3] Not supported by phonegap. [4] http://community.phonegap.com/nitobi/topics/how_to_implement_lzma?from_gsfn=true [5] http://stackoverflow.com/questions/823116/how-do-i-use-c-stl-containers-in-my-iphone-app Am 27.08.2011 10:34, schrieb Manuel Schneider: Hi, is this maybe also useful for ZIM - to make ZIM readers which are working cross-platform? As far as I understood phonegap is mainly a framework to create mobile apps based on HTML 5. At least the display of ZIM contents should be simple then as we just need a HTML widget for that. But what about libraries needed to read file contents, such as zimlib? I couldn't find out if Phonegap itself supports native file access (so we could re-implement ZIM features with that) or if it allows the use of native libraries. /Manuel Am 27.08.2011 02:44, schrieb Tomasz Finc: Thanks for the super detailed write up Brion. I've been actively talking with the PhoneGap guys after doing some more research on this and it seems like a really good fit to have a consistent experience across a whole host of devices. What were looking at is not necessarily a lot of depth in every single platform but a lot of horizontal range. Phonegap platform support beats out Titanium pretty easily there. We'll be working a lot closer with the PhoneGap team going forward to quickly have something in the android store to start. If anyone is interested in helping then we'll have plenty of opportunities to join in. Over the next weeks we'll be adding bugs and sending out more calls to get involved. --tomasz On Tue, Aug 16, 2011 at 1:50 PM, Brion Vibberbr...@pobox.com wrote: On Tue, Aug 16, 2011 at 1:14 PM, Tomasz Finctf...@wikimedia.org wrote: I've been asking around on IRC but thought it would be good to open up to a larger audience. Has anyone here used PhoneGap (http://www.phonegap.com/) for mobile app development? I'm eager to get your thoughts and potentially brainstorm some new ideas. I haven't used PhoneGap except for some brief testing, but I have used Titanium Appcelerator, which is
Re: [Wikitech-l] Mobile bug Triage non-WMF devs wanted!
On Aug 15, 2011, at 6:27 PM, MZMcBride z...@mzmcbride.com wrote: Mark A. Hershberger wrote: This Wednesday, I'll be conducting a bug triage of bugs related to mobile devices and the new MobileFrontend Extension. In order to get as much non-WMF interest as possible, I'm announcing the triage two days early. If you have a wiki that you would like to add mobile support to, then this is the triage for you! You'll have a chance to talk to developers about the issues and, if you can help with PHP development, you'll be able to see which bugs are most important to you to be fixed and even get some hints to begin diving into the code yourself. The MobileFrontend extension (http://www.mediawiki.org/wiki/Extension:MobileFrontend) is about to go into a test deployment on Wikipedia, so this is the perfect time to get involved! Here is are the bugs that I'm going to be choosing from for this triage. If you want to make sure a particular mobile-related bug is addressed in this Triage, email me the bug # and then join us on Wednesday. If you see something here that you'd like to try to fix, even better! Is the MobileFrontend extension development being monitored or reviewed by any senior developers? Yes, it has been reviewed. I took a look at the code today and it seemed incredibly strange. Could you send along some examples please. Some of its layout and architecture doesn't seem to be consistent with MediaWiki conventions/style and a lot of code (particularly variable assignments) looked duplicative. Can you please provide an example. Some revisions are also apparently being pushed live without any outside review. Yes, this is known. Every effort has been made to get eyes on every change, but some things have been pushed quickly for testing and to meet our schedule for the opt-in launch. This isn't particularly related to the bug triage, per se, I realize. Thanks, for your feedback. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile bug Triage ‹ non-WMF devs wanted!
On Aug 15, 2011, at 6:54 PM, K. Peachey p858sn...@gmail.com wrote: On Tue, Aug 16, 2011 at 11:45 AM, Patrick Reilly prei...@wikimedia.org wrote: Some revisions are also apparently being pushed live without any outside review. Yes, this is known. Every effort has been made to get eyes on every change, but some things have been pushed quickly for testing and to meet our schedule for the opt-in launch. I was under the view that all code that went live on the cluster had to be reviewed in CR by someone else for security reasons, has this since changed? No. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile bug Triage ? non-WMF devs wanted!
On Tue, Aug 16, 2011 at 3:26 AM, Max Semenik maxsem.w...@gmail.com wrote: On Tue, Aug 16, 2011 at 7:15 AM, MZMcBride z...@mzmcbride.com wrote: Rather than something sane and predictable for the URL parameter to view the standard (non-mobile) site (such as useFormat=standard), the code uses ?mAction=view_normal_site. As I commented in CodeReview today, a boolean parameter (?disableImages=1) has now been complemented with a completely separate parameter (?enableImages=1) rather than using ?disableImages=0, which I find to be very strange. Also, a stylistic nitpick: MediaWiki usually doesn't camelCase for URL parameters, so useFormat=... should ideally be changed to useformat for consistency. Duly Noted. Probably, this could also achieved with $wgActionPaths-style rewrite rules, e.g. en.wikipedia.org/mobile/Artticle_Name ? This variable was originally supposed to just be temporary as a way to force the mobile render. I'll look into converting it to this approach. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile bug Triage ? non-WMF devs wanted!
On Tue, Aug 16, 2011 at 3:25 AM, Tomasz Finc tf...@wikimedia.org wrote: I'll let Patrick respond to the more technical questions but Brion Vibber has been doing the majority of the reviews for this. He's been helped by Reedy and Aaron for some of the revisions as well. --tomasz On Mon, Aug 15, 2011 at 8:15 PM, MZMcBride z...@mzmcbride.com wrote: Patrick Reilly wrote: On Aug 15, 2011, at 6:27 PM, MZMcBride z...@mzmcbride.com wrote: Is the MobileFrontend extension development being monitored or reviewed by any senior developers? Yes, it has been reviewed. By whom? Please see Tomasz's comment. I took a look at the code today and it seemed incredibly strange. Could you send along some examples please. The use of a views directory containing .html.php files stuck out to me. As far as I know, this is the only extension in Wikimedia's SVN repo using this type of code structure. It looks like a holdover from the old Ruby code. Is that right? Is it going to be rewritten? Yes, you are correct it is a holdover from the old Ruby code. It could be rewritten to be more in-line with the standards. Some of its layout and architecture doesn't seem to be consistent with MediaWiki conventions/style and a lot of code (particularly variable assignments) looked duplicative. Can you please provide an example. Variables such as $randomButton are defined four times in the same file (extensions/MobileFrontend/MobileFrontend.php). Yes, those view related variables could be created as class level variables instead avoiding the duplication. I don't know too much about PHP, but it seemed very strange. Is there a reason for the duplication? Not really any good technical reason. It was mostly due to the views being slightly refactored. Could it be reduced? Yes. In general, the URL parameters are odd. I'm not sure if the English Wikipedia is running the newest code, but if you visit a URL such as http://en.wikipedia.org/w/index.php?title=Main_PageuseFormat=mobile, none of the links within it maintain the useFormat parameter, including and especially the links at the bottom. This is by design. The useFormat parameter is used only to force the mobile view. The main way that the extension is invoked is via the X-Device header. If you click one of the links at the bottom such as enable images on the mobile site, it removes all parameters including the ?title= parameter. This could be easily changed. Thanks, for the feedback. Rather than something sane and predictable for the URL parameter to view the standard (non-mobile) site (such as useFormat=standard), the code uses ?mAction=view_normal_site. This could also be easily changed for consistency sake. As I commented in CodeReview today, a boolean parameter (?disableImages=1) has now been complemented with a completely separate parameter (?enableImages=1) rather than using ?disableImages=0, which I find to be very strange. Okay, duly noted. The HTML at the bottom of the page at http://en.wikipedia.org/w/index.php?title=Main_PageuseFormat=mobile appears to also be completely invalid (pasted below): div id='copyright'Text is available under the a rel=license href=http://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attrib ution-ShareAlike_3.0_Unported_LicenseCreative Commons Attribution-ShareAlike License/aa rel=license href=http://creativecommons.org/licenses/by-sa/3.0/; style=display:none;/a; additional terms may apply. See a href=http://wikimediafoundation.org/wiki/Terms_of_use;Terms of use/a for details.br/ Wikipediareg; is a registered trademark of the a href=http://www.wikimediafoundation.org/;Wikimedia Foundation, Inc./a, a non-profit organization.br //lili class=noprinta class='internal' href=http://en.wikipedia.org/wiki/Wikipedia:Contact_us;Contact us/a/div /div The copyright is not part of the mobile extension it is core to media wiki. As far as I can see, the code is defining list items without specifying a ul or ol pair. One of the li elements is unclosed. And there's also some very strange display:none; code in this snippet. All of this seems very odd and quirky. I believe some of this quirkiness would be mitigated by using pre-built functions and following established coding styles, rather than using DIY templates. This is NOT part of the template. Again, I'm wondering which senior developer (or even non-senior developer) is reviewing this code. Some clarification on that would be appreciated. It has been provided. I've probably written about ten lines of PHP in my life, so feel free to tell me off if these comments are out of left field and/or don't make any sense. They make sense and are appreciated. These were just my observations from reading through some of the code today. I appreciate you taking the time to do that. Some revisions are also apparently being pushed live without any outside review. Yes, this is known. Every effort
Re: [Wikitech-l] Mobile bug Triage ? non-WMF devs wanted!
On Tue, Aug 16, 2011 at 3:36 AM, MZMcBride z...@mzmcbride.com wrote: Tomasz Finc wrote: I'll let Patrick respond to the more technical questions but Brion Vibber has been doing the majority of the reviews for this. He's been helped by Reedy and Aaron for some of the revisions as well. [19:33:57] Myra brion: Have you been reviewing MobileFrontend? [19:34:05] brion Myra, nope Brion did indeed provide the original code review of the Mobile Frontend extension. It has not changed significantly since that time. He has NOT been providing ongoing reviews since that time. http://toolserver.org/~mwbot/logs/%23mediawiki/20110815.txt MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mobile bug Triage ? non-WMF devs wanted!
On Tue, Aug 16, 2011 at 3:37 AM, bawolff bawolff...@gmail.com wrote: Message: 4 Date: Mon, 15 Aug 2011 19:49:40 -0400 From: mhershber...@wikimedia.org (Mark A. Hershberger) Subject: [Wikitech-l] Mobile bug Triage ? non-WMF devs wanted! To: Wikitech List wikitech-l@lists.wikimedia.org Message-ID: 87k4aeme0b@everybody.org Content-Type: text/plain; charset=utf-8 What: ?Mobile? bug triage When: Wednesday, August 17, 17:00UTC Time zone conversion: http://hexm.de/5r Where: #wikimedia-dev on freenode Use http://webchat.freenode.net/ if you don't have an IRC client This Wednesday, I'll be conducting a bug triage of bugs related to mobile devices and the new MobileFrontend Extension. In order to get as much non-WMF interest as possible, I'm announcing the triage two days early. If you have a wiki that you would like to add mobile support to, then this is the triage for you! You'll have a chance to talk to developers about the issues and, if you can help with PHP development, you'll be able to see which bugs are most important to you to be fixed and even get some hints to begin diving into the code yourself. If we're trying to attract non-wmf devs, parts of the extension seems very wmf specific (or do you mean we're trying to attract volunteer devs who only care about Wikipedia?). For example, at one part there is a check hardcoding things specific to the wmf server setup: stripos( $_SERVER['HTTP_VIA'], '.wikimedia.org:3128' ) !== false ) This is needed to work around a caching issue. I guess we should wrap that around a config variable that is specific to our environment. Or, provide the functionality in another way. There's another line doing stuff like: $featuredArticle = $this-mainPage-getElementById( 'mp-tfa' ); $newsItems = $this-mainPage-getElementById( 'mp-itn' ); Which I assume is a refrence to class names used on the english wikipedia's main page. Yes, it is a reference to the main page class names. We could also take the config variable approach. I personally feel (without actually looking at the issues involved, so take this with salt) that its bad to hardcode such things even if its only going to be used by wmf, since they can change. Duly noted. I appreciate your thoughts on the matter. However if we're aiming for third party re-use, then hardcoding such things is definitely a bad idea. Okay, we'll see what we can do to fix that issue. Or, at least mitigate any risk for third parties. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Updated status on MobileFrontend testing
Thanks, for this Tomasz. — Patrick On Mon, Aug 8, 2011 at 5:12 PM, Tomasz Finc tf...@wikimedia.org wrote: Greetings all, I got a couple of reports that it was a bit confusing to track where we were with the MobileFrontend testing so I updated our deployment page. Hopefully its easier now to understand what the Ruby gateway is still doing vs mobile frontend. http://www.mediawiki.org/wiki/MobileFrontend/Deployment#Status Let me know if you have any questions. --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] testing mobile browsers?
On Mon, Jul 11, 2011 at 1:36 PM, Brion Vibber br...@pobox.com wrote: On Mon, Jul 11, 2011 at 12:36 PM, Tomasz Finc tf...@wikimedia.org wrote: Firefox is tough as the current version has the exact same UA on mobile phones AND tablets. And since we don't redirect tablets we haven't switched it over yet. Anyone know why they did that? Mozilla generally recommends using CSS media queries and other client-side techs for adapting your pages to small or large screened-devices; while this is generally a good idea, it doesn't help directly with an issue like this where we'd really prefer to know a binary device claiming to have a tiny freaky screen or anything else so we can divide people down the mobile-optimized or regular web site paths. (We need to support older/more primitive phones that don't handle any of this stuff.) There are a couple closed-with-extreme-prejudice bugzilla entries like this: https://bugzilla.mozilla.org/show_bug.cgi?id=625238 https://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/43d566ca1333234e?pli=1 which mostly look like they're about wanting / not wanting whole gobs of device data in the user-agent string. All *we* really want is are you a small screen - include 'Mobile' in the UA or otherwise - don't include 'Mobile' in the UA... it may or may not be worth seeing if that can get added in as a compatibility thing, however I'm not sure offhand how easy it actually would be to detect whether such a flag should be added or not. I know that iOS has an explicit way to find out whether the app is running in the phone-style UI (iPhone, iPod Touch, and iPhone-targeted apps running on iPad in compat mode) or the tablet-style UI (iPad). I don't know if there's an equivalent on Android. An alternative if that can't be shoehorned in upstream is to do a JavaScript-side check while loading the regular web view; if we're in a browser where CSS media queries detect a tiny mobile screen, and we don't have a redirect preference cookie, then do the redirection after the fact. (And optionally set a default state for the per-browser preference cookie so we only have to do the test once instead of every visit?) I like this idea and think that we could implement it well. Also, this seems like it would be a good solution moving forward. As, it would just continue to work without the need to constantly update UA detection, etc. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: WMF engineering promotions and role changes
Congratulations, Rob, Tomasz, Alolita, Mark and Tim! Now we have another reason to party this coming Friday. ;) — Patrick On Mon, Jun 20, 2011 at 5:58 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, I’m pleased to announce the following promotions and role changes in engineering, effective immediately. * Rob Lanphier is the Director of Platform Engineering. * Tomasz Finc is the Director of Mobile and Special Projects. * Alolita Sharma is the acting Director of Features Engineering. Alolita has gracefully agreed to take on this role, for which we’re kicking off a full search process. * Mark Bergsma is now the Lead Operations Architect, reporting to CT. * Tim Starling is now the Lead Platform Architect, reporting to Rob. I’ll explain a bit more what these roles mean below, but first, please join me in congratulating Rob, Tomasz, Alolita, Mark and Tim! :-) Let me also take this opportunity to thank Danese Cooper for helping to build and professionalize the Wikimedia Foundation engineering organization as Wikimedia’s CTO. She also set these changes in motion, and our overall strategy is one that we’ve begun developing and socializing together in the last few months. Here’s how these roles fit together. The engineering department is principally structured into four sub-departments, each headed by a director who is the functional manager of all people within that sub-department: * Technical Operations - CT Woo: Keep Wikimedia Foundation sites and services running, increase uptime and performance, support code deployments, and ensure recoverability of data and services. * Platform Engineering - Rob Lanphier: Maintain and support the MediaWiki platform; ensure reliability, maintainability, and performance of our software; lead the release management process; grow and nurture the developer community and ecosystem. * Features Engineering - Alolita Sharma (Acting): Advance Wikimedia’s strategic priorities by focusing resources on specific feature projects such as the visual editor, or interventions designed to increase editor retention. * Mobile and Special Projects - Tomasz Finc: Advance Wikimedia’s mobile platform and ensure that mobile devices are fully considered across the engineering development process; execute projects with strong overlapping requirements (e.g. offline delivery of Wikimedia content). We’re also recognizing the importance of architectural engineering leadership in the development of a mature engineering organization (which also represents an additional career path for our distinguished engineers beyond “become a manager”). The three architects - Tim, Mark and Brion - will work together as follows: * Brion Vibber, as Lead Software Architect, has key architectural responsibility for getting MediaWiki ready to be the world’s leading tool for mass collaboration, by enabling the development of new technologies like the visual editor (his current priority), real-time collaboration, improved discussion systems, etc. This also includes architectural leadership to support bottom-up feature development. Brion reports directly to me. * Mark Bergsma, as Lead Operations Architect, is responsible for creating and communicating the vision and roadmap for the infrastructure needed to run all Wikimedia projects, for ensuring the design/implementation of our operating environment is reliable, scalable, supportable, secure and cost-effective, and for driving cross-functional alignment, especially with other engineering functions. * Tim Starling, as Lead Platform Architect, is responsible for the performance, stability, security and architectural cleanliness of the MediaWiki platform. Tim is leading potentially transformative engineering projects like the HipHop support in MediaWiki. He’s also a key mentor to all MediaWiki developers and is keeping us honest while we’re pursuing our feature dreams. In addition, we’re considering the shape of product and project management outside the Director-level leadership in the department. Currently, Howie Fung (Senior Product Manager) and Dario Taraborelli (Senior Research Analyst) are continuing to support our feature development projects to ensure that 1) development is aligned with strategic priorities, 2) we’re focusing the development on the needs of the user, 3) we’re making data-driven decisions and working effectively with the global wiki research community, 4) we’re engaging with the Wikimedia editor and reader community on complex feature development projects. I’m taking on the role of VP of Engineering and Product Development, on an interim basis for now. We’re not going to immediately hire either for that role or a CTO role. Thanks to Mark, Tim and Brion, we have very strong architectural leadership in the department. Moreover, we’ve got more than enough disruptive change as an engineering organization to absorb for now, so we’ve decided that it doesn’t make sense
Re: [Wikitech-l] Mobile site rewrite implementation
The reason that I went the route of creating an extension vs a skin was that I wanted the most flexibility in adapting the content for mobile device rendering. There are a number of sections that need to be removed from the final output in order to render the content effectively on mobile devices. So, being able to use a PHP output buffer handling is a nice feature. I also wanted the ability to use many of the features that are available when writing an extension to hook into core functionality. -- Patrick On Wed, May 11, 2011 at 3:56 PM, MZMcBride z...@mzmcbride.com wrote: A few people (including myself) have expressed some concerns about the way in which the mobile site is being rewritten. I don't really think Bugzilla or MediaWiki.org are the appropriate forums for this, but this list probably is. (I assume Patrick Reilly is subscribed to this list. CC'ing him in any case.) The previous mobile site was written in Ruby and does some of its own parsing. The rewrite is written in PHP and many people seem to agree that it should be some sort of skin system so that it's adaptable to other MediaWiki installations and doesn't try to do anything too crazy (like re-implement the parser). There are concerns that the current rewrite approach (in SVN in an extension called PatchOutputMobile for those curious) isn't the best, but it's completely possible there are reasons for the way it's being re-implemented. Patrick or Tomasz: can you give an overview of what the current re-implementation strategy is? * Relevant bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=25558 * Relevant MediaWiki page: http://www.mediawiki.org/wiki/Mobile_site_rewrite MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
