Re: [Wikitech-l] Deploymight highlights - week of December 16th
Did the PHP upgrade affect tidy in some way? Some pages are severely broken e.g. by unbalanced div or table tags (both Vector and monobook). Only two reports on #wikimedia-tech in two days, so maybe no real change, but I used not to hear any. :) https://www.mediawiki.org/w/index.php?title=Extension%3ABugzilla_Reportsdiff=844734oldid=773425 https://it.wikipedia.org/w/index.php?title=Utente%3AVale14orladiff=63098711oldid=54419590 Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Deploymight highlights - week of December 16th
I wonder if this is 38273 revived. Like 58042 was. Cirrus hasn't changed this code so I'm reasonably confident it isn't us this time. Though it is still possible given that we're on mediawikiwiki and itwiki. On Wed, Dec 18, 2013 at 4:23 AM, Federico Leva (Nemo) nemow...@gmail.comwrote: Did the PHP upgrade affect tidy in some way? Some pages are severely broken e.g. by unbalanced div or table tags (both Vector and monobook). Only two reports on #wikimedia-tech in two days, so maybe no real change, but I used not to hear any. :) https://www.mediawiki.org/w/index.php?title=Extension% 3ABugzilla_Reportsdiff=844734oldid=773425 https://it.wikipedia.org/w/index.php?title=Utente% 3AVale14orladiff=63098711oldid=54419590 Nemo ___ 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] Lowering limitation of the score extension
Le mardi 17 décembre 2013 à 10:36 -0700, Brian Wolff a écrit :
I'm not very familiar with lilypond, so there is probably a better
way, but I was able to generate that fret board with code like:
score raw
\markup {\fret-diagram #s:0.75;6-x;5-x;4-o;3-2;2-3;1-2;}
\score {
\new Score { c1 }
\midi { }
}
\header { tagline = ##f}
/score
See
https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandboxoldid=586519066
Oh, great thank you. Do you have any idea how you may make a landscape
oriented diagram with the \markup function? Or more generaly, how do you
translate this kind of code :
\new FretBoards {
\once \override FretBoard
#'(fret-diagram-details fret-count) = #3
\override FretBoard
#'(fret-diagram-details orientation) = #'landscape
\override FretBoard
#'(fret-diagram-details barre-type) = #'none
\override FretBoard
#'(fret-diagram-details finger-code) = #'below-string
\override FretBoards.FretBoard #'size = #'2
\override FretBoard
#'(fret-diagram-details finger-code) = #'in-dot
…
to apply it to the \new Score { c1 } you are using ?
--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] Re-evaluating MediaWiki ResourceLoader's debug mode
On Wed, 18 Dec 2013 03:28:36 +0100, Krinkle krinklem...@gmail.com wrote: In fact, we could drop debug mode entirely (short of its effect on debug-modules being loaded, it wouldn’t affect the way modules are packages anymore). While this would be lovely, some browsers don't support source maps, and people do debug things on these too. I agree debug mode is rarely useful – but sometimes it is. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Jenkins tests queue should proceed faster
Hello, Gerrit changes are processed by a daemon known as Zuul which triggers Jenkins jobs and report back to Gerrit as the infamous jenkins-bot. Since I upgraded Zuul in May 2013, the jobs were not processed as fast as we would have wanted. There were issues on Jenkins side, faulty configuration on the server but we eventually reached some acceptable state. Still. During busy hours (Europe evening, SF morning) with the l10n bot submitting half a thousand of changes, we would have to wait up to half an hour to get a test report. I spent most of the night debugging and reproducing that issue on my computer then went to bed. A few minutes ago, I have deployed a change that would make Zuul process changes way faster. The change is ridiculously small since it is just about commenting two lines: https://gerrit.wikimedia.org/r/102465 It basically prevents Zuul from updating builds descriptions pages in Jenkins until all builds have been completed. Since updating a build description takes roughly 500ms, that is saving a ton of waiting time. Thanks a ton to at least Ori, Timo, Qchris, RobH, manybubles and basically everyone around using the CI platform in one way or another. I have monitored the upgrade for the last few minutes in production and that works as expected. The rollback plan is: Revert https://gerrit.wikimedia.org/r/102465 Merge revert on gallium: - cd /usr/local/src/zuul - git pull - as root: * http_proxy=. python setup.py install * /etc/init.d/zuul restart I don't think that it is needed though. Will monitor again tonight during the real peak hour. For reference the bug is https://bugzilla.wikimedia.org/48025 which I believe is now properly fixed. Merry Christmas. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jenkins tests queue should proceed faster
Thank you very much, Antoine. בתאריך 18 בדצמ 2013 19:43, מאת Antoine Musso hashar+...@free.fr: Hello, Gerrit changes are processed by a daemon known as Zuul which triggers Jenkins jobs and report back to Gerrit as the infamous jenkins-bot. Since I upgraded Zuul in May 2013, the jobs were not processed as fast as we would have wanted. There were issues on Jenkins side, faulty configuration on the server but we eventually reached some acceptable state. Still. During busy hours (Europe evening, SF morning) with the l10n bot submitting half a thousand of changes, we would have to wait up to half an hour to get a test report. I spent most of the night debugging and reproducing that issue on my computer then went to bed. A few minutes ago, I have deployed a change that would make Zuul process changes way faster. The change is ridiculously small since it is just about commenting two lines: https://gerrit.wikimedia.org/r/102465 It basically prevents Zuul from updating builds descriptions pages in Jenkins until all builds have been completed. Since updating a build description takes roughly 500ms, that is saving a ton of waiting time. Thanks a ton to at least Ori, Timo, Qchris, RobH, manybubles and basically everyone around using the CI platform in one way or another. I have monitored the upgrade for the last few minutes in production and that works as expected. The rollback plan is: Revert https://gerrit.wikimedia.org/r/102465 Merge revert on gallium: - cd /usr/local/src/zuul - git pull - as root: * http_proxy=. python setup.py install * /etc/init.d/zuul restart I don't think that it is needed though. Will monitor again tonight during the real peak hour. For reference the bug is https://bugzilla.wikimedia.org/48025 which I believe is now properly fixed. Merry Christmas. -- 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] Wikipedia mobile app rewrite early test builds available
Third work sprint is coming to a close with basic page save functionality. Menus are very much in flux and far from final, especially on iOS! :) * Android: http://dumps.wikimedia.org/android/apps-android-wikipedia-dev-sprint3.apk * iOS: on testflightapp.com (email notifications sent to our recently trimmed beta list) As always, remember the source is out there: $ git clone https://gerrit.wikimedia.org/r/apps/android/wikipedia apps -android-wikipedia $ git clone https://gerrit.wikimedia.org/r/apps/ios/wikipedia apps-ios- wikipedia Patches are welcome through Gerrit or via our GitHub mirrors (they'll end up in Gerrit in the long run), and please don't be afraid to come talk to us in #wikimedia-mobile on Freenode IRC. We don't bite! Much. -- brion On Wed, Dec 4, 2013 at 4:38 PM, Brion Vibber bvib...@wikimedia.org wrote: Second work sprint on the new apps is wrapping up; while we still have some visual polish to do there are builds available snapshotting today's state. This sprint has added some basic data storage to the app, tracking page view history and making it visible through the sidebar menu (on Android) or by directly tapping the W icon (on iOS, will have a menu soon!). We're just starting to put together some of the new UI elements, so the next couple of sprint releases are going to be much more visually interesting... and with a little more expansion of the database we'll soon start caching pages to allow offline reading... Exciting times! * Android: http://dumps.wikimedia.org/android/apps-android-wikipedia -dev-sprint2.apk * iOS: on testflightapp.com (email notifications sent to our recently trimmed beta list) On Wed, Nov 20, 2013 at 6:33 PM, Brion Vibber bvib...@wikimedia.orgwrote: As folks may be aware, over in the Wikimedia Mobile Apps team we're starting a refresh of the Wikipedia mobile apps for Android and iOS, which have not been updated in a while and are now wayyy behind the mobile web in features and UI awesomeness. The new apps are using native UI around the content web view, which lets us integrate with the system better than the old PhoneGap-based HTML app, and provide long-desired features like pinch-to-zoom in the article view. Our first 2-week work sprint is finishing up, and builds of current state are available: * Android: http://dumps.wikimedia.org/android/apps-android-wikipedia-dev-sprint1.apk * iOS: on testflightapp.com (email notifications sent to our recently trimmed beta list) Both versions are pretty bare-bones, so don't be surprised by missing icons, toolbar buttons that don't work, or incomplete design. :) This first feature sprint concentrated on getting search basic content loading working. You can type into the search box, the search results include thumbnails, and you can select a search result to load the article. You can also click on internal links in both iOS and Android versions, though they get a little flaky from there out. :) Back/forward is not yet implemented on iOS; back works on Android but there's no forward. Note also the pretty animation when following links on Android -- neat! Next sprint's release should look more polished, as we'll have some more navigation working, and the first sprint stuff prettied up to better match design: https://upload.wikimedia.org/wikipedia/commons/c/c8/Search-overlay-01.png For in-progress design UX ideas for the new app, see https://www.mediawiki.org/wiki/Wikipedia_App_Design Note that you may or may not need to manually uninstall the old app if it's present first. If you want to try the iOS version and aren't on the beta list you'll have to build it yourself on a Mac with XCode 5, and then you can only install it on your device if you are a registered iOS developer (thank Apple's restrictions on third-party app installations!): $ git clone https://gerrit.wikimedia.org/r/apps/ios/wikipediaapps-ios-wikipedia (Unfortunately we cannot add new people to the iOS beta list until Apple clears out old entries from our 100-max device database, either at the end of the calendar year or in February when our membership rolls over. Yeah, I'm serious...) And of course you can build the Android version too, and run it with no restrictions: $ git clone https://gerrit.wikimedia.org/r/apps/android/wikipediaapps-android-wikipedia Note that there's separate work going to revitalize the Wikipedia app for Firefox OS, which will remain HTML5-based as that's how native Firefox apps work! That's being spearheaded by the Wikimedia Mobile Partnerships Wikipedia Zero team. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC deadline this Friday, December 20
Hi everyone, Everything I said below still stands, except now there are only two days, so please make the most of them. Don't make me break out the caps lock. I'll do it. :-) Thanks Rob -- Forwarded message -- From: Rob Lanphier ro...@wikimedia.org Date: Wed, Dec 11, 2013 at 12:41 PM Subject: RFC deadline approaching for Arch Summit: December 20 To: Wikimedia developers wikitech-l@lists.wikimedia.org Hi everyone, We're just over a week away from the Friday, December 20 deadline for RFCs as items to consider at the Architecture Summit.[1] That's not a hard and fast rule (we've never done this before), but we should definitely have a reasonable amount of time between the point an RFC is proposed and being discussed at the Architecture Summit. Ideally, we'll have taken care of everything that's reasonable to take care of via mailing list/IRC/other online meeting, and really be down the things that require face-to-face time to accomplish. It's my hope that we're not just nibbling at the edges, but that we're actually going to talk about things that will substantially modernize our architecture and reduce our technical debt. I believe there are RFCs in the list and in the works that do that, but I also know there are areas we've discussed informally in the past that we've never set to writing. Many of the RFCs cover important areas of incremental improvement, but not all of the changes we need to make have such small increments. Anyway, RFC submission page is here: https://www.mediawiki.org/wiki/Requests_for_comment Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC deadline this Friday, December 20
On Dec 18, 2013, at 3:30 PM, Rob Lanphier ro...@wikimedia.org wrote: Hi everyone, Everything I said below still stands, except now there are only two days, so please make the most of them. I have been working on some draft proposals here: https://www.mediawiki.org/wiki/User:Owyn I think that a few of them are ready for feedback so I have moved them onto the list. Some of these ideas are things that Wikia has already implemented to some degree or another, and some of them are just things that we’d like to see some discussion about. https://www.mediawiki.org/wiki/Requests_for_comment/MVC_Framework - We have our own mvc framework that we’ve used to build pretty much everything in the last 2 years. The developers don’t complain about it, so it must be relatively decent. :) The original design came from Inez (who is working on VisualEditor now) and myself, and it’s been hacked up a bit from where we originally started but we think the core of it is an improvement over QuickTemplates and XML. https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_Refactor - We usually stick to the normal extension/hook mechanisms for our own stuff, but in the case of the UserMailer it was impossible, so we had to modify it heavily. A lot of the things that we added are basic features like priority and categories (used by our mail sending backend) and the ability to send HTML mail. The User Mailer is an example of a core class which is not designed to be extended, and it probably should be refactored. https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_Refactor - The output page class is another monolithic class which is a mixture of output pipelining/sequencing functions and helper functions. It creates a lot of data which is used by the skin, but also emits raw HTML and headers in a way that makes it hard to override functionality. A lot of this could probably be split up to separate the data from the rendering of the HTML page. https://www.mediawiki.org/wiki/Requests_for_comment/SQL_Framework - This one is more for fun but it does address something we feel is a pretty big deficiency in the core API's. We wrote a fluent style SQL library and we’ve started using it to build SQL queries in our more complicated data/reporting extensions. We like it a lot better than the core mediawiki database interface which uses positional arrays of key/value pairs. The current database api makes it almost impossible to visualize what the actual SQL is going to be, so you have to just run the code and capture the debug output. With this library, you can build up a query as an object. It has some nice side effects like the ability to cache results without extra boilerplate, and efficiently transform the query output without having to make extra passes through the result set. The remaining proposals on my user page might be interesting for someone to look at, but they are either too vague or overlap with existing proposals for really serious consideration and I plan on merging them with the appropriate RFC’s soon. Definitely appreciate any comments/questions! Owen (@Wikia) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
