Wikitech-l March 2014

wikitech-l@lists.wikimedia.org

188 participants
231 discussions

[IRC] static logs from irc channels are inaccessible for reading
by Petr Bena 13 Mar '14

13 Mar '14

Hi, due to labs migration to eqiad irc logs that are typically at bots.wmflabs.org/~wm-bot/logs are now down. They will be back as soon as https://bugzilla.wikimedia.org/show_bug.cgi?id=62234 is fixed. For now you can use alternative log browser available at tools: http://tools.wmflabs.org/wm-bot/logs/ this one doesn't provide static logs which are tarballed, but on other hand it has colors \o/ I will send a mail once the logs are back on-line P.S. no worries, the IRC bot is still collecting the logs, they just can't be displayed on webserver, which is not accessible from outside now.

1 1

Instances of project bots are going to be deleted
by Petr Bena 13 Mar '14

13 Mar '14

Hi, We sent tons of warnings in past that you should migrate all bots or tools (should you run any) from bots project on wikimedia labs to tools project. The servers are now going to be deleted within few days, so this is last notification I am going to send regarding this. So far I have revoked access from basically everyone except project admins so I believe that it is "safe to delete" the instances as nobody complained that they lost the access. Let me know if you have any questions :)

1 0

short RfC review meeting Wednesday: five quick decisions
by Sumana Harihareswara 13 Mar '14

13 Mar '14

This Wednesday, 2100-21:30 UTC, let's have a thirty-minute RfC review meeting to check on a few proposals to consolidate, and whether a few authors have done their next steps from the last few months. (If people want to answer these questions onlist/onwiki that's fine too.) https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-12 I have some open questions: 1. Configuration (database) RfCs: original<https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database>, RFC 2<https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2>, and JSON onwiki<https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wi…>. Shall we ask authors to consolidate by a certain date? 2. URL shortener<https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener>(and URL Shortener Service<https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener_service_f…>, probably to be consolidated). Do we have the implementation details Tim wanted? 3. Assert <https://www.mediawiki.org/wiki/Requests_for_comment/Assert>. Any particular enthusiasm or next steps here? 4. Linker refactor<https://www.mediawiki.org/wiki/Requests_for_comment/Linker_refactor>. Any initial comments? (onwiki comments welcome also) 5. your RfC here? I recently updated lots of entries in the https://www.mediawiki.org/wiki/Requests_for_comment table so please check those out and comment on those where appropriate, and suggest RfCs to cover on Wednesday. We'll talk in #wikimedia-office on Freenode, at 2100 UTC on March 12: http://www.worldtimebuddy.com/?qm=1&lid=2950159,100,524901,5128581&h=512858… Moscow: 1am Thursday 13 March Berlin: 22:00 12 March New York: 5pm March 12 San Francisco: 2pm March 12 Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

3 4

mediawiki-announce no longer forwarded to mediawiki-l?
by Bartosz Dziewoński 13 Mar '14

13 Mar '14

Is mediawiki-announce no longer forwarded to mediawiki-l? I'm pretty sure it used to be, and I'm pretty sure it is no longer. (Or maybe everyone always sent everyting to both?) (I was not subscribed to -announce and haven't received any notifications about today's releases, that's what prompted me.) -- Matma Rex

2 1

What mentors need to know
by Quim Gil 12 Mar '14

12 Mar '14

Hi, we seem to have many new brave mentors again, ready to push new GSoC and OPW projects. Great! This might help you doing the right thing, now, during the program, and after: https://www.mediawiki.org/wiki/Mentorship_programs/Possible_mentors Right now you must assure that your candidates * get their proposals ready edit by edit in wiki pages at mediawiki.org * are as good as they seem to be, assigning microtasks to them * apply formally to GSoC and/or OPW -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Requesting feedback on Project- UploadWizard: Openstreetmap embedding
by Anu George Enchackal 12 Mar '14

12 Mar '14

Hi Everyone, I would like to invite your feedback on [1] prototype of Project-'UploadWizard:OSM embedding' [ user/password is mediawiki/mw ]. This project is about enhancing the image upload process for Wikimedia Commons.The main goal of the OSM embedding project is to provide map interface to the UploadWizard. We can not expect each and every uploader to know exact location where image being uploaded was taken, or to use location enabled camera/phone to take the image. With introduction of map interface, uploader can easily choose location coordinates for uploaded images. Detailed project description can be found at [2]. Functioning of embedded map : - On valid coordinates/location inputs widget first loads a static map which on 'click' will initialize leaflet powered dynamic map - Address search - ' type' or 'importance' specific zoom for various kinds of locations on address search - .Dynamic updation of coordinate fields and location field on leaflet map interaction and vice versa Kindly give your suggestions for map widget- design as it needs to be improved, also propose features and/or improvements in current features. Please share your insights at [3]. [1]http://uploadwizard-osm.bitnamiapp.com/mediawiki/Special:UploadWizard [2] https://www.mediawiki.org/wiki/UploadWizard_OSM_map_embedding [3] https://www.mediawiki.org/wiki/Talk:UploadWizard_OSM_map_embedding Best regards Anu G Enchackal

3 4

useskin=minerva
by Jon Robson 12 Mar '14

12 Mar '14

You can now apply the mobile skin to the desktop site [1]. Wahhhh?! To cut a long story short, to help MobileFrontend and VisualEditor integrate nicely with one another, we needed the mobile skin to be registered as a valid skin. We've previously avoided this as we didn't want to surface this in the Special:Preferences (a side effect of doing so). Kaldari however found a way we can supress it there, so thus we went and registered it [1]. I encourage editors to check how their stuff looks in the minerva skin on a small window size. This should make mobile optimisation a lot easier for you! :) [1] http://en.wikipedia.beta.wmflabs.org/wiki/Forty-seven_Ronin?useskin=minerva [2] https://gerrit.wikimedia.org/r/#/c/118037/

4 5

Wikipedia App Reboots, HTTPS, and Wikipedia Zero (was Re: [WikimediaMobile] Wikimedia Commons mobile photo uploader app updated on iOS and Android)
by Adam Baso 12 Mar '14

12 Mar '14

Another note in case you missed it earlier. If your'e looking in general to test the Wikipedia app reboot, at the moment the Android APK can be downloaded from https://releases.wikimedia.org/mobile/android/apps-android-wikipedia-sprint… bugs can be filed via Bugzilla. The iOS build is currently internal due to installation limits, although simulator and debugging stuff can be done on the latest beta of Xcode. I also forgot to mention my peer Yuri's great work! The guy knuckled down to considerably revise Varnish scripts, reviewed and helped me improve code, and offered really good advice on API-app interaction. Thanks Yuri! -Adam On Wed, Mar 5, 2014 at 4:16 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > I realized I should be clear that the "rebooted apps" I mention are "the > future Wikipedia mobile app"s mentioned earlier in the thread. Sorry if any > confusion. > > -Adam > > > On Wed, Mar 5, 2014 at 11:43 AM, Adam Baso <abaso(a)wikimedia.org> wrote: > >> +mobile-l >> >> Greetings. Rupert, an update! >> >> The rebooted Android (Android 2.3+) and iOS (iOS 6+) apps will have >> Wikipedia Zero flourishes built into them, making it possible for the user >> to know whether the app access is free of data usage charges. The rebooted >> apps are tentatively slated for store submission at the end of the month. >> The flourishes will hinge on each operator's zero-rating of HTTPS. >> >> Likewise, HTTPS contributory features are about to be introduced on the >> Wikipedia Zero mobile web experience as well for operators that zero-rate >> HTTPS. >> >> WMF is starting the work with partner operators to add support for >> zero-rating of HTTPS. There will be, at least, technical hurdles >> (networking equipment architecture varies) in this transition, but it's >> underway! Indeed, we have some carriers that have noted support for HTTPS >> zero-rating already. >> >> I'm very much grateful to Brion, Yuvi, and Monte for their assistance >> while I added code to the Android and iOS platforms, and am happy to get to >> work with them more while putting final touches in place this month. Props >> to Faidon, Mark, and Brandon in Ops Engineering as well on helping us >> overcome some rather non-trivial hurdles in order to retain good >> performance and maintainability while adding HTTPS support. >> >> -Adam >> >> >> On Mon, Aug 26, 2013 at 3:34 PM, Brion Vibber <bvibber(a)wikimedia.org>wrote: >> >>> On Mon, Aug 26, 2013 at 8:19 AM, Adam Baso <abaso(a)wikimedia.org> wrote: >>> >>> > Rupert, I saw your question regarding Wikipedia Zero. Wikipedia Zero is >>> > currently targeted for the mobile web, but I'll take this question >>> back to >>> > the business team as to whether we'd be able to support zero-rating of >>> apps >>> > traffic at some point in the future, at least in locales where moderate >>> > bandwidth is available. >>> > >>> >>> I think that once the zero-rating is switched to support HTTPS by using >>> IP-based instead of Deep Packet Inspection-based HTTP sniffing, ISP >>> partners wouldn't actually be able to distinguish between mobile web and >>> mobile apps content unless we actively choose to make them use separate >>> IPs >>> and domain names. >>> >>> Especially if, as we think we're going to, the future Wikipedia mobile >>> app >>> will consist mostly of native code widgets and modules that plug into the >>> web site embedded in a web control... it'll be loading mostly the same >>> web >>> pages from the same servers, but running a different mix of JavaScript. >>> >>> -- brion >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >> >> >

2 2

Review requested on a logging fix for deleted pages
by Matthew Flaschen 12 Mar '14

12 Mar '14

I could use a review on Gerrit 113525 (https://gerrit.wikimedia.org/r/#/c/113525/), "Store page_id in logging table for deletions and make queryable". If you can look at it, I'd appreciate it. Basically, it logs the page_id for deleted pages. Before, it generally did not return a page_id for deleted pages from the log API. The exception was if the page existed at query-time. However, this was the ID for the *current* page, not the one actually deleted. Besides fixing the API, this means of course it's also in the logging table itself, which will help with anyone using that table for analysis. Thanks, Matt Flaschen

1 0

Gerrit Commit Wars
by Tyler Romeo 12 Mar '14

12 Mar '14

Hi everybody, I cannot believe I have to say something about this, but I guess it's no surprise. Wikipedia has a notorious policy against edit warring, where users are encouraged to discuss changes and achieve consensus before blindly reverting. This applies even more so to Gerrit, since changes to software have a lot bigger effect. Here's a nice example: https://gerrit.wikimedia.org/r/114400 https://gerrit.wikimedia.org/r/117234 https://gerrit.wikimedia.org/r/117247 Some key points to note here: * The revert commit was not linked to on the original commit * The time between the revert patch being uploaded and +2ed was a mere two minutes * All the reviewers on the revert patch were also reviewers on the original patch This is unacceptable behavior, and is extremely disrespectful to the developers here. If you are going to revert a patch for reasons other than a blatant code review issue (such as a fatal error or the likes), you should *at the very least* give the original patch reviewers time to understand why the patch is being reverted and give their input on the matter. Otherwise it defeats the entire point of the code review process and Gerrit in the first place. The argument being made in this specific case is that the change broke the workflow of mobile, and that the revert was announced on mobile-l. This is not sufficient for a number of reasons: 1) not everybody is subscribed to mobile-l, so you cannot expect the original reviewers to see or know about it 2) this is an issue with MobileFrontend, not MediaWiki core 3) code being merged does not automatically cause a deployment, and if code being deployed breaks something in production, it is the operations team's job to undeploy that change Overall, the lesson to take away here is to be more communicative with other developers, especially when you are negating their changes or decisions. Thanks in advance, *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

29 95

← Newer
1
...
13
14
15
16
17
18
19
...
24
Older →

Jump to page:

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 March 2014