[Wikitech-l] ★ Wikimedia developers, Sergey Samoylov оставил для вас сообщение
Вы можете прочитать сообщение и ответить на него через наш чат. Откройте своё сообщение http://eu1.badoo.com/0311318950/in/fIgvQLfMBoI/?lang_id=2g=57-0-4m=29mid=530f2b5d0002031f985d00a1ed77007a Они ждут встречи с вами: Если ссылка не работает, скопируйте и вставьте её в адресную строку браузера. До скорого! Команда Badoo Вы получили это письмо от Badoo Trading Limited (почтовый адрес ниже). Если вы не хотите получать уведомления от Badoo, нажмите здесь: https://eu1.badoo.com/impersonation.phtml?lang_id=2email=wikitech-l%40wikimedia.orgblock_code=4ddf1dm=29mid=530f2b5d0002031f985d00a1ed77007ag=0-0-4. Badoo Trading Limited зарегистрирована в Англии и Уэльсе под номером CRN 7540255 по юридическому адресу: Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ★ Wikitech L, Sergey Samoylov оставил для вас сообщение
Вы можете прочитать сообщение и ответить на него через наш чат. Откройте своё сообщение http://eu1.badoo.com/0311318950/in/G1x.KSiSP6U/?lang_id=2g=57-0-4m=29mid=530f2b5d0002031f985d00e7ed77007c Они ждут встречи с вами: Если ссылка не работает, скопируйте и вставьте её в адресную строку браузера. До скорого! Команда Badoo Вы получили это письмо от Badoo Trading Limited (почтовый адрес ниже). Если вы не хотите получать уведомления от Badoo, нажмите здесь: https://eu1.badoo.com/impersonation.phtml?lang_id=2email=wikitech-l%40wikipedia.orgblock_code=252bf1m=29mid=530f2b5d0002031f985d00e7ed77007cg=0-0-4. Badoo Trading Limited зарегистрирована в Англии и Уэльсе под номером CRN 7540255 по юридическому адресу: Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 3d Online Geometry Viewer
On Tue, Jan 14, 2014 at 12:28 AM, Eugene Zelenko eugene.zele...@gmail.com wrote: Currently we have a support for .g (BRL-CAD's binary file format) files, but BRL-CAD has a long list of supported formats so anything that BRL-CAD can import will be supported. BRL-CAD can export files as X3D but it cannot import them yet :( . The file formats that BRL-CAD can import are ASCII, AutoCad DXF, Elysium Neutral Facetted, EUCLID, FASTGEN, IGES, Jack, NASTRAN, STL, TANKILL, Unigraphics and Viewpoint which can then be internally converted to .g file and exported to .obj for 3D online geometry viewer. I think will be good idea to investigate, if there open 3D formats, i. e. non-proprietary and not covered by patents. .g format by BRL-CAD is an open format. I saw in those Ideas page referred by David Cucena, that preferred format is X3D, I looked around and found that there can be workarounds through which X3D can be imported in three.js and viewed, same goes for using OBJ, it can be viewed in three.js but as much as I understood from http://brlcad.org/VolumeIV-Converting_Geometry.pdf I don't think we can import them in BRL-CAD yet. There is a GSoC project this year on importing X3D files in BRL-CAD though, so it's being worked upon. BRL-CAD is also currently working on (read about partial support http://brlcad.org/wiki/STEP) STEP(Standard for the Exchange of Product model data) format (ISO_10303), which is the standard open format for 3D models. -- Inderpreet Singh Ekoankar Sahai ishwerdas.com facebook.com/okayinder https://kippt.com/okayinder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Preview of the proposal for MediaWiki Homepage
On 02/26/2014 06:06 PM, Brian Wolff wrote: You would have to go a bit into the js side of things to do that. I'm not sure that's a good idea though. In my experience (on a wiki that used flagged revs), if the newbies see one thing, and regular users see another, what ends up happening is no one notices when the newbie oriented page is broken as the newbies don't know how to report issues (or even recognize something is an issue), which is bad because its the newbies where it is most important to make a good first impression. Replied at https://www.mediawiki.org/wiki/Talk:MediaWiki/Homepage_redesign/Preview#What_can_you_see_without_scrolling Pasted here for convenience: Ok, so no different content to different users. What about the option of clipping content? Is it technically possible to offer unclipped content to anonymous users, clipped to registered users? About the clipping itself, https://www.mediawiki.org/wiki/Template:Collapse_top does clip content but we would need a nicer implementation. For instance, we could keep the title (now Community Collaboration) and a expand type of arrow. Anonymous users would see the full homepage with a minimize type of arrow. Or something along these lines. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Retina/Hi-DPI images 'srcset' compatibility update: Chrome 34 native support
Chrome beta (version 34) now includes native 'srcset' support: http://www.chromestatus.com/features/4644337115725824 This means that on high-density screens like a Retina MacBook Pro, the 1.5x or 2.0x-size image will be loaded automatically by the browser, and our JavaScript hack disables itself. I've confirmed that this works as expected with Chrome 34 beta and 35 'canary' builds. This means faster page loads on hi-dpi devices and less unnecessary default loading of 1.0x-size images when they're not going to be used. Presumably this is also coming to Chrome for Android, where it's more important due to the large number of Android devices running at 1.5 or 2.0 (or even 3.0) display density (hdpi/xhdpi/xxhdpi): http://developer.android.com/about/dashboards/index.html#Screens -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from this week's quarterly review of the Foundation's Core features team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Core_features/February_2014 On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, to increase accountability and create more opportunities for course corrections and resourcing adjustments as necessary, Sue's asked me and Howie Fung to set up a quarterly project evaluation process, starting with our highest priority initiatives. These are, according to Sue's narrowing focus recommendations which were approved by the Board [1]: - Visual Editor - Mobile (mobile contributions + Wikipedia Zero) - Editor Engagement (also known as the E2 and E3 teams) - Funds Dissemination Committe and expanded grant-making capacity I'm proposing the following initial schedule: January: - Editor Engagement Experiments February: - Visual Editor - Mobile (Contribs + Zero) March: - Editor Engagement Features (Echo, Flow projects) - Funds Dissemination Committee We'll try doing this on the same day or adjacent to the monthly metrics meetings [2], since the team(s) will give a presentation on their recent progress, which will help set some context that would otherwise need to be covered in the quarterly review itself. This will also create open opportunities for feedback and questions. My goal is to do this in a manner where even though the quarterly review meetings themselves are internal, the outcomes are captured as meeting minutes and shared publicly, which is why I'm starting this discussion on a public list as well. I've created a wiki page here which we can use to discuss the concept further: https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We're slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC review Thursday afternoon/Friday morning on UI styling
This is in about 100 minutes in #wikimedia-office. -Sumana On Wed, Feb 26, 2014 at 1:29 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Brion and Tim hope to chat with Jon Robson, Pau Giner, Juliusz Gonera, and other interested folks about the current UI styling RFCs. More information: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 These meetings move around so we can sometimes accommodate Europe, Australia, or various bits of North America, depending on who needs to be in the meeting. This time the meeting's 00:00 UTC until 1:00 UTC on Feb 28: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=2day=28hour=0min=0sec=0p1=224p2=240p3=179 San Francisco: Thursday, February 27 at 4 PM Berlin: Friday, 28 February at 1 AM Mumbai: Friday, 28 February at 5:30 AM Sydney: Friday, 28 February 2014 at 11 AM As usual, it's in IRC, in #wikimedia-office on Freenode. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Adventures in creating new repos / jenkins jobs
Hey all, I recently had a new repository created; and I wanted to create some jobs for it. I dutifully created and had merged: https://gerrit.wikimedia.org/r/#/c/115968/ https://gerrit.wikimedia.org/r/#/c/115967/ Hashar told me I then needed to follow the instructions on [1] to push the jobs to jenkins. Running the script myself was only pain; it kept erroring out while trying to create the job. Marktraceur managed to create the jobs after much kicking down the door aka running the script multiple times. It appears that the problem is that https://integration.mediawiki.org/ci/createItem?name=mwext-FundraisingChart-lint301s to https://integration.mediawiki.org/?... So that's a problem? We're still not sure why Mark was able to create the jobs with perseverance though. Another problem that I'm seeing is in responsibilities -- supposedly only jenkins admins (wmf developers) can submit jobs (and then only when it works). And then, only people with root on galium can apply the Zuul configs. To me this is clearly not something the average developer is supposed to be doing. Would it make sense to have QChris / ^demon create the standard jobs when they create the repository? [1] https://www.mediawiki.org/wiki/Continuous_integration/Tutorials/Adding_a_MediaWiki_extension ~Matt Walker Wikimedia Foundation Fundraising Technology Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Adventures in creating new repos / jenkins jobs
On Thu, Feb 27, 2014 at 04:28:52PM -0800, Matthew Walker wrote: Hashar told me I then needed to follow the instructions on [1] to push the jobs to jenkins. Running the script myself was only pain; it kept erroring out while trying to create the job. Marktraceur managed to create the jobs after much kicking down the door aka running the script multiple times. Hilariously, the jobs still don't run. I don't see the code getting checked out on Gallium, and the jobs are all marked LOST with no logs. I'm hopeful that this is an issue related to the repository still being empty, but this may be too-wishful thinking. https://gerrit.wikimedia.org/r/116008 -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC review Thursday afternoon/Friday morning on UI styling
The log's now on https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27. I apologise; we didn't have time to get to Allow styling in templateshttps://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templatesor Inline diffs https://www.mediawiki.org/wiki/Requests_for_comment/Inline_diffs. In the future I'll only schedule 2 RFCs per session. Outcomes: Pau Giner is going to finish the Grid RFC and add certain suggested details so that it can be accepted. It's probably a good idea for us to revisit the implementation in April to see what the Language team has done with it. And more research is required on advanced possibilities for scoping site CSS (this will probably fall to Juliusz Gonera). Next meeting: March 5th on passwords and TitleValue - setting time soon. https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-05 On Thu, Feb 27, 2014 at 5:19 PM, Sumana Harihareswara suma...@wikimedia.org wrote: This is in about 100 minutes in #wikimedia-office. -Sumana On Wed, Feb 26, 2014 at 1:29 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Brion and Tim hope to chat with Jon Robson, Pau Giner, Juliusz Gonera, and other interested folks about the current UI styling RFCs. More information: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 These meetings move around so we can sometimes accommodate Europe, Australia, or various bits of North America, depending on who needs to be in the meeting. This time the meeting's 00:00 UTC until 1:00 UTC on Feb 28: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=2day=28hour=0min=0sec=0p1=224p2=240p3=179 San Francisco: Thursday, February 27 at 4 PM Berlin: Friday, 28 February at 1 AM Mumbai: Friday, 28 February at 5:30 AM Sydney: Friday, 28 February 2014 at 11 AM As usual, it's in IRC, in #wikimedia-office on Freenode. Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Adventures in creating new repos / jenkins jobs
On Thu, Feb 27, 2014 at 4:36 PM, Mark Holmquist mtrac...@member.fsf.orgwrote: On Thu, Feb 27, 2014 at 04:28:52PM -0800, Matthew Walker wrote: Hashar told me I then needed to follow the instructions on [1] to push the jobs to jenkins. Running the script myself was only pain; it kept erroring out while trying to create the job. Marktraceur managed to create the jobs after much kicking down the door aka running the script multiple times. Hilariously, the jobs still don't run. I don't see the code getting checked out on Gallium, and the jobs are all marked LOST with no logs. I'm hopeful that this is an issue related to the repository still being empty, but this may be too-wishful thinking. https://gerrit.wikimedia.org/r/116008 No such luck; we pushed the initial rough code into the repo; and I rebased the above on top of it -- the jobs still fail. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.3, 1.21.6 and 1.19.12
Hello everyone, I would like to announce the release of MediaWiki 1.22.3, 1.21.6 and 1.19.12. These releases fix a number of security related bugs that could affect users of MediaWiki. In addition, MediaWiki 1.22.3 is a maintenance release. It fixes several bugs. You can consult the RELEASE-NOTES-1.22 file for the full list of changes in this version. Download links are given at the end of this email. == Security fixes == * (bug 60771) SECURITY: Disallow uploading SVG files using non-whitelisted namespaces. Also disallow iframe elements. User will get an error including the namespace name if they use a non- whitelisted namespace. * (bug 61346) SECURITY: Make token comparison use constant time. It seems like our token comparison would be vulnerable to timing attacks. This will take constant time. * (bug 61362) SECURITY: API: Don't find links in the middle of api.php links. == Bug fixes in 1.22.3 == * (bug 53710) Add sequence support for upsert in DatabaseOracle in the same way as in selectInsert * (bug 60231, 58719) Various fixes to job running code in Wiki.php: Make it async on Windows. Fixed possible invalid filename errors on Windows. Redirect output to dev/null to avoid hanging PHP. * (bug 60083) Correct sequence name for fresh Postgres installation. Spotted by gebhkla * (bug 60531) Avoid variable naming conflicts in DatabasePostgres::selectSQLText. Spotted by gebhkla * (bug 60094) Fix rebuildall.php fatal error with PostgreSQL. The fix for 47055 introduced a fatal error when running rebuildall.php. This is a workaround suggested by gebhkla on Bugzilla. It just checks to make sure $options is actually an array before calling array_search on it. * (bug 43817c12) Add error handling if descriptionmsg isn't defined for extension. * (bug 60543) Special:PrefixIndex omits stripprefix=1 for Next page link. Full release notes for 1.22.3: https://www.mediawiki.org/wiki/Release_notes/1.22 Full release notes for 1.21.6: https://www.mediawiki.org/wiki/Release_notes/1.21 Full release notes for 1.19.12: https://www.mediawiki.org/wiki/Release_notes/1.19 For information about how to upgrade, see https://www.mediawiki.org/wiki/Manual:Upgrading ** 1.22.3 ** Download: http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.tar.gz Patch to previous version (1.22.2), without interface text: http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.patch.gz Interface text changes: http://releases.wikimedia.org/mediawiki/1.22/mediawiki-i18n-1.22.3.patch.gz GPG signatures: http://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.3.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.3.patch.gz.sig http://releases.wikimedia.org/mediawiki/1.22/mediawiki-i18n-1.22.3.patch.gz.sig Public keys: https://www.mediawiki.org/keys/keys.html ** 1.21.6 ** Download: http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.tar.gz Patch to previous version (1.21.3), without interface text: http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.patch.gz Interface text changes: http://releases.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.6.patch.gz GPG signatures: http://releases.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.6.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.21/mediawiki-1.21.6.patch.gz.sig http://releases.wikimedia.org/mediawiki/1.21/mediawiki-i18n-1.21.6.patch.gz.sig Public keys: https://www.mediawiki.org/keys/keys.html ** 1.19.12 ** Download: http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.tar.gz Patch to previous version (1.19.11), without interface text: http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.patch.gz Interface text changes: http://releases.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.12.patch.gz GPG signatures: http://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.12.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.tar.gz.sig http://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.12.patch.gz.sig http://releases.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.12.patch.gz.sig Public keys: https://www.mediawiki.org/keys/keys.html --mglaser ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.3, 1.21.6 and 1.19.12
* (bug 61346) SECURITY: Make token comparison use constant time. It seems like our token comparison would be vulnerable to timing attacks. This will take constant time. Not to be a grammar nazi, but that should presumably be something along the lines of Using constant time comparison will prevent this instead of This will take constant time, as that could be interpreted as the attack would take constant time. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.3, 1.21.6 and 1.19.12
I note that there are security fixes in these release's -- did I miss Chris' email about these patches or are we moving away from the model where we send out an email to the list a couple of days before release? ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Thu, Feb 27, 2014 at 6:55 PM, Brian Wolff bawo...@gmail.com wrote: * (bug 61346) SECURITY: Make token comparison use constant time. It seems like our token comparison would be vulnerable to timing attacks. This will take constant time. Not to be a grammar nazi, but that should presumably be something along the lines of Using constant time comparison will prevent this instead of This will take constant time, as that could be interpreted as the attack would take constant time. --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
