Re: [Wikitech-l] IRC meeting for RFC review
On 25/09/13 13:31, Steven Walling wrote: On Sun, Sep 22, 2013 at 8:26 PM, Tim Starling tstarl...@wikimedia.orgwrote: I would like to have an open IRC meeting for RFC review, on Tuesday 24 September at 22:00 UTC (S.F. 3pm). We will work through a few old, neglected RFCs, and maybe consider a few new ones, depending on the interests of those present. The IRC channel will be #mediawiki-rfc. Just wanted to say thanks for setting this up. The meeting was well-run and I hope you do them in the future. One question... IRC office hour logs have been posted to Meta in the past. Can we post RFC discussion logs to MediaWiki.org? I have posted the relevant log excerpts to the talk pages of the three RFCs we discussed in detail: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/URL_shortener#IRC_meeting_2013-09-24 https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Support_for_user-specific_page_lists_in_core#IRC_meeting_2013-09-24 https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Retained_account_data_self-discovery#IRC_meeting_2013-09-24 -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Product Team Announcements: Oliver, Dan, and Nick
On 25/09/2013 06:40, a b wrote: On Wed, Sep 25, 2013 at 4:30 AM, Howie Fung hf...@wikimedia.org wrote: Everyone, I have a few announcements (apologies for the delay as this was posted to an internal WMF staff mailing list a few weeks ago). First, I'd like to announce Oliver's transition to Product Analyst (contractor, full time). As many of you know, Oliver has been working with us for the past ~2 years as a Community Liaison. As Community Liaison, he has helped provide the critical link between the English Wikipedia editing community and WMF product teams on Page Curation, Echo, AFT, and VisualEditor. Effective immediately, Oliver will be transitioning to the newly created role of Product Analyst. In this role, Oliver will support the Flow team in mapping out the myriad of complex workflows, templates, bots, and other craziness that happens on talk pages, and also providing analytical support to help the Flow team prioritize features. [*] So a staff member that gets blocked on wiki (By Arbcom no less) is basically getting getting a promotion, Where as volunteers that get blocked and have access to some of our other services such as OTRS get their permissions revoked. WONDERFUL! *sigh* If you're going to troll, why let facts get in the way - On the other note, congratulation Oliver, Dan and Nick!!! :) KTC -- Katie Chan Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent the view of any organisation the author is associated with or employed by. Experience is a good school but the fees are high. - Heinrich Heine ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code reviewers registry
Le 24/09/13 23:56, C. Scott Ananian a écrit : Our core developers get a lot of patches to review. Once something drops down past the first page in Gerrit, it's lost forever. I have enough people asking me for review that I only rely on my Gerrit dashboard. So indeed, old patches are usually out of my view. Last time I looked at the rotting changes in mediawiki/core, most of them received some reviews and are pending actions from the original author. We should probably triage them and then either finish the code or abandon it. Backing up here, I'm assuming that our focus is on fostering new developers. Old hands know who to add as reviewers, and know to pester them if they don't get a review in a reasonable time. I'm wondering if there's some way the bot can shepherd the review process a little further past the add reviewers stage. For example, can we identify new contributors -- those with less than N patches merged, say? Have the bot target those for help with reviewers, and then maintain, say, a status board where we can keep an eye on those patches and make sure they make it through the process? The OpenStack Foundation (they use Gerrit and a similar workflow of core people approving changes), has build a review dashboard that assign a score to changes: http://status.openstack.org/reviews/ Related code is on github: https://github.com/openstack-infra/reviewday#reviewday The score algorithm is in reviewday/mergeprop.py [1]. As an example a regression hotfix get a score of 350 while a minor feature get 35. As the patch get older, it will receives additional points to bump it. They then have all core people on a rolling one day duty where their role is to approve changes, assign reviewers and ask them to do reviews. That is tedious, but only for a day: https://wiki.openstack.org/wiki/Nova/ReviewDays We can surely reuse reviewday for our own use, that will need some code written to interact with Bugzilla to fetch the keywords/priority and assign scores. I am to busy to babysit such a project on a labs instance, but will be more than happy to get the change merged upstream if need be (tip folks are in #openstack-infra). [1] https://github.com/openstack-infra/reviewday/blob/master/reviewday/mergeprop.py -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
The zero ESI change is now live, but is enabled only when X-FORCE-ESI header is set to 1. Also, it won't work until varnish enables ESI support for zero requests (see dochttps://www.varnish-cache.org/docs/3.0/tutorial/esi.html ) I propose the following deployment steps: 1) set beresp.do_esi = true for all requests with X-CS header. (should not be enabled for javascript or any other non-html resources) This will let us measure ESI impact when HTML has no esi:include tag. 2) Enable X-FORCE-ESI header for one or more smaller carriers while monitoring the impact on varnish load 3) Enable ESI configuration flag for all zero partners 4) Remove cache variance on X-CS header On Tue, Jun 18, 2013 at 12:06 PM, Yuri Astrakhan yastrak...@wikimedia.orgwrote: Hi Mark, On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma m...@wikimedia.org wrote: * All non-local links always point to a redirector. On javascript capable devices, it will load carrier configuration and replace the link with local confirmation dialog box or direct link. Without javascript, redirector will either silently 301-redirect or show confirmation HTML. Links to images on ZERO.wiki and all external links are done in similar way. For M, you only want to do this when it's a zero carrier I guess? If not, just a straight link? Correct - two variants for M -- with ESI banner + redirect links, and without ESI + direct links. * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) I'm wondering, is there any HTML difference between M isZeroCarrier == TRUE and ZERO? Links maybe? Can we make those protocol relative perhaps? We might be able to kill the cache differences for the domain completely, while still supporting both URLs externally. Yes - M+Carrier -- has images, ZERO -- redirect links to images ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AbuseFilter error codes and MobileFrontend
Juliusz Gonera wrote: On 09/23/2013 06:48 PM, Andrew Garrett wrote: You should know about this change[1], which corrects the error messages to be more in line with the general case, as well as adding some metadata. It's not been approved yet, so I'm nudging a few reviewers. You can also determine which mobile edits are hitting filters, by looking for edits in the filter log which have 'user_mobile = 1' set. I'm not sure I quite remember how to search in that way, but I'll look into it. [1] https://gerrit.wikimedia.org/r/#/c/80137/ I'm not sure if I understand what are the implications of this change for the mobile editor. Does it change the code key into error-msg key? If yes, should I rely on error-msg rather than code after this patch is merged to determine what is a warning and what is disallowed? You will now start to receive a consistent error message of 'abusefilter-aborted' included in the error.code property of the output instead of the hodgepodge of other AbuseFilter errors, which were returned in a nonstandard format. You can still find the detailed error message in other properties of the error object. — Andrew Garrett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Product Team Announcements: Oliver, Dan, and Nick
On Wed, 25 Sep 2013 07:40:58 +0200, a b cheeseyapac...@gmail.com wrote: So a staff member that gets blocked on wiki (By Arbcom no less) He has been desysopped, not blocked. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [Reminder] Language Engineering IRC Office hour on September 25, 2013 at 1700 UTC
Hello, This is reminder that the Wikimedia Language Engineering team will be hosting an IRC office hour from 1700 to 1800UTC later today on #wikimedia-office (FreeNode). Please see below for the event details. Thanks Runa === Event Details === What: WMF Language Engineering Office hour When: September 25, 2013 (Wednesday). 1700-1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130925T1700 Where: IRC Channel #wikimedia-office on FreeNode -- Forwarded message -- From: Runa Bhattacharjee rbhattachar...@wikimedia.org Date: Sat, Sep 21, 2013 at 12:49 AM Subject: Language Engineering IRC Office hour on September 25, 2013 at 1700 UTC To: Wikimedia developers wikitech-l@lists.wikimedia.org, Wikimedia Mailing List wikimedi...@lists.wikimedia.org, wikitech-ambassad...@lists.wikimedia.org, MediaWiki internationalisation mediawiki-i...@lists.wikimedia.org [Cross-posted] Hello, The Wikimedia Language Engineering team will be hosting an IRC office hour on Wednesday, September 25, 2013 between 17:00 - 18:00 UTC. (See below for timezone conversion and other details.) We will be talking about some of our projects that are in development, a short round up from Google Summer of Code and then taking questions for the remaining time. If there are things that you would like to bring to our attention then this would be a good time to do so. Questions can also be sent to me directly before the event. See you there! Thanks Runa === Event Details === What: WMF Language Engineering Office hour When: September 25, 2013 (Wednesday). 1700-1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130925T1700 Where: IRC Channel #wikimedia-office on FreeNode -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Language Extension Bundle 2013.09 release
Hello,
I would like to announce the release of MediaWiki Language Extension
Bundle 2013.09. This bundle is compatible with MediaWiki 1.20.7 and
MediaWiki 1.21.2.
* Download:
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.09.tar.bz2
* sha256sum: 2ac55639aeb43a6f3d198a87e10111f673eae1115225de072be73a1fa2052ab2
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ freenode
Release notes for each extension are below.
Kartik Mistry
== CLDR ==
* Updated to CLDR v 24.
* Localisation updates.
== Babel and CleanChanges ==
* Only localisation updates.
== Translate ==
* Added initial support for insertables. This will be helpful in
typing and copy-paste of syntax like $1 and plural especially on
tablets (bug 38350). More about this feature:
http://laxstrom.name/blag/2013/09/18/insertables-in-translate-extension-make-translating-easier/
* Removed non-breaking spaces in the language list shown on the top of
translatable pages. Non-breaking spaces makes the only places where
the browser can break the line is the languages containing a
(breaking) space, which are not the right places (bug 49900).
* Display the loading indicator in message group selector while
loading (bug 46829).
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Web fonts are no longer loaded for autonyms in the interlanguage
area. This is a temporary change to improve performance; a more
comprehensive fix may be done in the future.
* Use correct name for wiki content language. An incorrect name could
appear when anonymous user could not change the language, and the
language of the translation differed from the content language (bug
49738).
* Revert font preview correctly when pressing cancel button (bug 53203).
* Make the Cancel and Apply buttons applicable for all modules (bug 53256).
* Fixed some edge cases in which the IME menu went off-screen.
* Show an autonym in the input menu title for languages that don't
have input methods instead of an empty title.
* Ability to customize the time out for the IME selector widget. This
helps during development/debugging sessions where you often wish that
the widget stayed little longer.
=== Fonts ===
* Set OskiEast font default for Canadian Syllabic language.
* Set Phetsarath font default for Lao language.
* Updated TuladhaJejeg font for Javanese to 2.0.1 version.
* Fixed name of Estrangelo Edessa font.
=== Input methods ===
* Added and improved Persian keyboard.
Thanks to entire Language Engineering team for making this release possible!
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Two updates about pywikibot (formerly pywikipedia)
Hello folks! *Name of pywikipedia or pywikipediabot is officially changed to pywikibot, please update local documentation *Bug tracker of pywikibot is changed from sf.net to bugzilla. Open bugs was imported from there by a bot that legoktm has written [1], So don't file new bugs in sf.net anymore and keep tracking your reports (if you has reported something) in bugzilla, If you like you can hack some of the bugs and make it fixed! [2] and please update local documentation [1] https://git.wikimedia.org/summary/pywikibot%2Fsf-export.git [2] https://bugzilla.wikimedia.org/buglist.cgi?list_id=236065short_desc=.resolution=---query_format=advancedbug_status=NEWshort_desc_type=regexpproduct=Pywikibot Cheers -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikitech-ambassadors] Two updates about pywikibot (formerly pywikipedia)
On Wed, Sep 25, 2013 at 7:11 PM, Luca Martinelli martinellil...@gmail.comwrote: May I just ask why all names have been changed? wikipedia is redundant, because you can run this framework in any mediawiki-based wiki, and It's simpler and shorter, We used this name in git, nightly distributor, bugzilla, etc. but It was not official And why all those new nested folders? Just curiosity. Sorry but I can't understand what you are saying L. Il giorno 25/set/2013 17:27, Amir Ladsgroup ladsgr...@gmail.com ha scritto: Hello folks! *Name of pywikipedia or pywikipediabot is officially changed to pywikibot, please update local documentation *Bug tracker of pywikibot is changed from sf.net to bugzilla. Open bugs was imported from there by a bot that legoktm has written [1], So don't file new bugs in sf.net anymore and keep tracking your reports (if you has reported something) in bugzilla, If you like you can hack some of the bugs and make it fixed! [2] and please update local documentation [1] https://git.wikimedia.org/summary/pywikibot%2Fsf-export.git [2] https://bugzilla.wikimedia.org/buglist.cgi?list_id=236065short_desc=.resolution=---query_format=advancedbug_status=NEWshort_desc_type=regexpproduct=Pywikibot Cheers -- Amir ___ Wikitech-ambassadors mailing list wikitech-ambassad...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors ___ Wikitech-ambassadors mailing list wikitech-ambassad...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors best -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] FOSDEM update
Hi, about FOSDEM - https://www.mediawiki.org/wiki/Events/FOSDEM Brussels / 1 2 February 2014 On 1 Oct we will know whether our proposal for a Wiki DevRoom has been accepted or not. This is a DevRoom we have proposed together with XWiki and TikiWiki and is open to all wiki topics. If we we get it accepted we will organize a call for participation for this DevRoom. The call for main track session proposals is open until 1 Oct. https://fosdem.org/2014/news/2013-08-06-call-for-participation/ ... and the call for lightning talks and stands is open until 20 Nov. https://fosdem.org/2014/news/2013-09-17-call-for-participation-part-two/ You are encouraged to submit lightning talk proposals! Don worry if you are unsure between submitting a session for a lightning talk or a devroom: you can contact both and then they suggest you what to do. Wikimedia wants to have a stand, and we have received an offer to help from the nascent Wikimedia Belgium chapter. Probably more help can be aggregated from CH, DE, FR, NL, UK + other tech contributors in the region? Let's do something really cool! To be discussed. -- 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
Re: [Wikitech-l] AbuseFilter error codes and MobileFrontend
On 09/25/2013 02:38 AM, Andrew Garrett wrote: On 09/23/2013 06:48 PM, Andrew Garrett wrote: You should know about this change[1], which corrects the error messages to be more in line with the general case, as well as adding some metadata. It's not been approved yet, so I'm nudging a few reviewers. You can also determine which mobile edits are hitting filters, by looking for edits in the filter log which have 'user_mobile = 1' set. I'm not sure I quite remember how to search in that way, but I'll look into it. [1] https://gerrit.wikimedia.org/r/#/c/80137/ I'm not sure if I understand what are the implications of this change for the mobile editor. Does it change the code key into error-msg key? If yes, should I rely on error-msg rather than code after this patch is merged to determine what is a warning and what is disallowed? You will now start to receive a consistent error message of 'abusefilter-aborted' included in the error.code property of the output instead of the hodgepodge of other AbuseFilter errors, which were returned in a nonstandard format. You can still find the detailed error message in other properties of the error object. I've just checked on my local instance and it seems that this patch does not change much for the MobileFrontend. As I stated in the first message, we need to distinguish between warnings and disallowed edits because they require different UI (either allow resubmitting or not). It seems that without this patch the only way to do this is looking at the `code` property and with this patch I should look at the `error-msg` property instead (and keep my fingers crossed that some admin didn't come up with a different word for warning). I understand that thanks to this patch we can be 100% sure that the error comes from AbuseFilter even if the `error-msg` has no abusefilter- prefix. However, we should also include some information which would allow us to figure out which action from Actions taken when matched box in filter config a given API response is referring to. That would be much more reliable than looking for abusefilter-warning- prefix which can be omitted by admins setting up the warning. -- Juliusz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ParserHooks 1.1 released
Hey all, I'm pleased to announce the 1.1 release of the ParserHooks library.ParserHooksis a small library that adds an object orientated and declarative parser hook interface on top of MediaWiki. https://github.com/wikimedia/mediawiki-extensions-ParserHooks/blob/master/README.md This new version simplifies the API a little and adds support for registering hook handlers as tag extensions. This library is now also used by the SubPageList extension. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle. Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the old branch becomes the branch new branch, merging everything from master like we do when making a new branch. In practice this would map out to the following: wmf-foo - 1.22wmf19 wmf-bar - 1.22wmf20 wmf-baz - 1.22wmf21 wmf-foo - 1.22wmf22 wmf-bar - 1.22wmf23 And so on and so forth. When creating the new branch we can tag the old one in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags. On the deployment side this is nice because we can just consistently have 3 branches live on the cluster rather than lingering old ones. Switching would be a matter of checking out and scapping rather than cloning and scapping. Too confusing? Alternative ideas? I'm open to most anything that will stop us making new branches all the time :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VE/Migration guide for gadgets developers
On Tue, Sep 24, 2013 at 11:45 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Roan, how did that go? Any links? :-) The code ended up being written and merged. The documentation ended up not being written before Wikimania, and then Life happened. Some Time Soon I hope to get around to actually writing this up properly. In the meantime, https://gerrit.wikimedia.org/r/#/c/75270/ fixes a ResourceLoader bug that fatally breaks VE's plugin infrastructure for on-wiki scripts (Gadgets and user/site JS), so until that's merged and deployed, the interface I'd be documenting doesn't actually work anyway. Another thing I'm gonna do soon is take the GSoC project code for Math and SyntaxHighlight and move it out of the VisualEditor extension into the respective extensions. That'll be a good showcase for the extension plugin integration, which does already work. Right after I get that done would be a good time to document this, because I'll have just gone through the process and know the pitfalls etc. first-hand. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkil...@gmail.com wrote:
wmf-foo - 1.22wmf19
wmf-bar - 1.22wmf20
wmf-baz - 1.22wmf21
wmf-foo - 1.22wmf22
wmf-bar - 1.22wmf23
This looks like it's exactly the same concept as slot0/slot1/slot2 in
Ryan's git-deploy proposal.
The objection that I would have to this is that it makes the
cherry-picking workflow less intuitive. You have to know which of
wmf-{foo,bar,baz} to cherry-pick to, rather than being able to
cherry-pick to wmf23 or whatever. Also, because the wmfN tags can only
be created after they're no longer live (because only at that point do
we know they'll have stopped changing), you can't actually find the
*current* wmfN anywhere, because it won't have been tagged yet.
The motivation is to stop making new branches all the time, but tags
and branches are equally cheap. A tag is just a frozen branch that
can't advance. If you're trying to tag something but it can still
change, use a branch. And that's what our deployment branches are,
IMO.
Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkil...@gmail.com wrote: So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle. What's actually the problem with expanding branches? Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the old branch becomes the branch new branch, merging everything from master like we do when making a new branch. It seems to me that reusing branch names could get real confusing... And so on and so forth. When creating the new branch we can tag the old one in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags. We could also do exactly that when retiring branches from production, without changing the naming schema. Transfer the branch tip to a tag, delete the branch, everybody's happy. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:01 PM, Roan Kattouw roan.katt...@gmail.comwrote:
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkil...@gmail.com wrote:
wmf-foo - 1.22wmf19
wmf-bar - 1.22wmf20
wmf-baz - 1.22wmf21
wmf-foo - 1.22wmf22
wmf-bar - 1.22wmf23
This looks like it's exactly the same concept as slot0/slot1/slot2 in
Ryan's git-deploy proposal.
The objection that I would have to this is that it makes the
cherry-picking workflow less intuitive. You have to know which of
wmf-{foo,bar,baz} to cherry-pick to, rather than being able to
cherry-pick to wmf23 or whatever. Also, because the wmfN tags can only
be created after they're no longer live (because only at that point do
we know they'll have stopped changing), you can't actually find the
*current* wmfN anywhere, because it won't have been tagged yet.
I agree, I think this would make the deployment process more error-prone.
How about having a legacy branch with tags for each wmf deployment that
isn't actually on the cluster? So then we only need 3ish branches (legacy,
and the current 2 in production), but deployers still work with wmf18,
wmf19, etc?
The motivation is to stop making new branches all the time, but tags
and branches are equally cheap. A tag is just a frozen branch that
can't advance. If you're trying to tag something but it can still
change, use a branch. And that's what our deployment branches are,
IMO.
Roan
___
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] VE/Migration guide for gadgets developers
i've also been writing the togetherjs extension out of tree from v.e. so have a little bit of experience there. a couple more apis could be stabilized to help extensions find ve instances on a page --scott On Wed, Sep 25, 2013 at 5:55 PM, Roan Kattouw roan.katt...@gmail.comwrote: On Tue, Sep 24, 2013 at 11:45 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Roan, how did that go? Any links? :-) The code ended up being written and merged. The documentation ended up not being written before Wikimania, and then Life happened. Some Time Soon I hope to get around to actually writing this up properly. In the meantime, https://gerrit.wikimedia.org/r/#/c/75270/ fixes a ResourceLoader bug that fatally breaks VE's plugin infrastructure for on-wiki scripts (Gadgets and user/site JS), so until that's merged and deployed, the interface I'd be documenting doesn't actually work anyway. Another thing I'm gonna do soon is take the GSoC project code for Math and SyntaxHighlight and move it out of the VisualEditor extension into the respective extensions. That'll be a good showcase for the extension plugin integration, which does already work. Right after I get that done would be a good time to document this, because I'll have just gone through the process and know the pitfalls etc. first-hand. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IRC meeting for RFC review
On 09/24/2013 11:54 PM, Tim Starling wrote: Can we post RFC discussion logs to MediaWiki.org? I have posted the relevant log excerpts to the talk pages of the three RFCs we discussed in detail: Participants of structured IRC meetings might also look at Bug 46377 - MeetBot for #wikimedia-office https://bugzilla.wikimedia.org/show_bug.cgi?id=46377 -- 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
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvib...@wikimedia.org wrote: On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkil...@gmail.com wrote: So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle. What's actually the problem with expanding branches? To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important. Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the old branch becomes the branch new branch, merging everything from master like we do when making a new branch. It seems to me that reusing branch names could get real confusing... Indeed. And so on and so forth. When creating the new branch we can tag the old one in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags. We could also do exactly that when retiring branches from production, without changing the naming schema. Transfer the branch tip to a tag, delete the branch, everybody's happy. :) I actually like this idea a lot and it's way less confusing than my idea. Unless anyone's got any objections I'm going to go ahead and do this for all the 1.20 and 1.21 wmf branches. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:46 PM, Chad innocentkil...@gmail.com wrote: I actually like this idea a lot and it's way less confusing than my idea. Unless anyone's got any objections I'm going to go ahead and do this for all the 1.20 and 1.21 wmf branches. Sounds good to me. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On 26.09.2013, 2:46 Chad wrote: On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvib...@wikimedia.org wrote: What's actually the problem with expanding branches? To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important. I always look it up at http://noc.wikimedia.org/conf/highlight.php?file=wikiversions.dat -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 4:01 PM, Max Semenik maxsem.w...@gmail.com wrote: On 26.09.2013, 2:46 Chad wrote: On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvib...@wikimedia.org wrote: What's actually the problem with expanding branches? To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important. I always look it up at http://noc.wikimedia.org/conf/highlight.php?file=wikiversions.dat You can, and you can also use `mwversionsinuse` on the cluster. When I'm on the command line and wanting to merge to a deployment branch I'd rather not have to switch to my browser or SSH in if I can get the info right there...I'm lazy :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposed release timeline
According to the Version lifecycle[1], MediaWiki 1.22 is slated for release on November 30th, at the very latest. In that vein, we've come up with a timeline for the release[2]. If we use this timeline and shoot for the latest date, we'll need to start the release process no later than October 19th. Please look over the timeline and the TBD section and provide feedback. Of course, if you see gaps or things that you can help clarify, please feel free to mention them on the talk page. Thanks, Mark. [1] https://www.mediawiki.org/wiki/Version_lifecycle [2] https://www.mediawiki.org/wiki/Project:Release_management/Release_timeline -- Mark A. Hershberger NicheWork LLC 717-271-1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: afch licensing question
Forwarding, with permission. For background the AFC Helper script is one that assists English Wikipedians reviewing pages in the Articles for Creation queue, which currently is severely backlogged. Any thoughts on the licensing issue, from folks with experience on the question of gadget/userscript licensing? -- Forwarded message -- From: Mr. Donald J. Fortier II technical...@yahoo.com Date: Wed, Sep 25, 2013 at 8:30 PM Subject: afch licensing question To: swall...@wikimedia.org swall...@wikimedia.org Per the discussion on https://github.com/WPAFC/afch/issues/61 one of the previous contributors to the project refuses to agree to relicense AFCH under the MIT license. Right now, the script is licensed under CC-BY-SA/GFDL, as it was originally coded on-wiki (per [[Wikipedia:Copyright]] -- all text-based contributions). This came about due to some confusion that can be seen https://github.com/WPAFC/afch/issues/60. So, we are unsure as to where to go from here. If we replace any code contributed to the project by the person that refuses to agree, can we dissolve any requirements to get him to agree? Is there enough contribution from him to actually worry about it as he hasn't actually written any functions, just converted some stuff from old school JavaScript to jQuery? Any advice/assistance on this would be appreciated. -- Steven Walling, Product Manager https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
