Hello all,
*TL;DR*: Reminder to please bike-shed at
[[mw:Phabricator/Diffusion/Callsign_naming_conventions]]
<https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conven…>
before
December.
Just when you thought it was safe, there's the next stage in our migration
of developer tools over to Phabricator: moving all our code into the
Diffusion module <https://www.mediawiki.org/wiki/Phabricator/Diffusion>.
This is *not* about doing code review in Phabricator; that task will be
left for another time. However, it does establish some immutable URLs and
so there's a lot of scope for discussion and verification about how exactly
we want to do things.
We currently use gitblit to provide our service at git.wikimedia.org ; it's
a down-stream, read-only, HTTPS service for browsing all our git repos.
We'd like to replace this service with the single platform of Phabricator
because (a) we need to make these decisions anyway for the code review
workstream, (b) fewer tools makes for a simpler learning environment for
newbies, and (c) more integrated tools makes for fewer hacky bots and "work
arounds" for everyone.
To explore what Diffusion looks like, compare:
- GitBlit:
http://git.wikimedia.org/summary/VisualEditor%2FVisualEditor.git
- GitHub: https://github.com/wikimedia/visualeditor
- Diffusion: https://phabricator.wikimedia.org/diffusion/VE/
We need to agree how we are going to name our repos, and much more
importantly because it can't change, what their "callsign" is. These will
be at the heart of e-mails, IRC notifications and git logs for a long time,
so it's important to get this right rather than regret it after the fact.
A handful of repos are so important and high-profile that we can use an
acronym without too much worry, like "MW" for MediaWiki or "VE" for
VisualEditor. For the rest, we need to make sure we've got a good enough
name that won't cause inconveniences or confusion, and doesn't repeat the
mistakes we've identified over time. We've learnt since the SVN to git
migration a few years ago that calling your repository "/core" is a bad
plan, for instance.
*Action request*
The proposed naming conventions
<https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conven…>
and
in particular the plan for what we'll call the existing repos
<https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conven…>
when we duplicate them would benefit from more people looking at them, if
only to say that you don't care. :-) We've had these under discussion since
October so you may well have seen these before.
We plan to declare the current list as "agreed" in a week's time (that is,
by the end of 1 December) unless there's significant on-going discussion.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
When I first started doing this for beta I did use a local tracking
branch. After about a week I switched to the cherry-pick and rebase
model. Keeping the changes as cherry-picks with the cron'd rebase
script has a few advantages in my opinion:
* It's easy to see what the delta from upstream is using the log
command I showed before (git log --color --pretty=oneline
--abbrev-commit origin/HEAD..HEAD).
* As things are merged upstream the rebase process drops the cherry-pick.
* People should be less tempted to make permanent "local hack" patches.
Ideally the only reason for having the custom puppet master in beta at
all is to allow testing of patches that are work in progress before
having them merged into the operations/puppet.git production branch
and to let us fix things quickly in beta without waiting for ops +2 on
the changes. The two cruddy local only patches that are/were there
were the result of a need to refactor that upstream wasn't ready for
at the time. Now that we have puppet3 and hiera available both of
these patches should be resolvable by introducing hiera vars.
Bryan
On Tue, Dec 2, 2014 at 5:53 AM, Mukunda Modell <mmodell(a)wikimedia.org> wrote:
> Is there any reason we don't have a branch on the git repo to hold these
> commits so that the beta environment doesn't need a bunch of transient
> state? This is exactly what branches are good for isn't it?
>
>
> On Monday, December 1, 2014, Bryan Davis <bd808(a)wikimedia.org> wrote:
>>
>> On Mon, Dec 1, 2014 at 4:17 PM, Greg Grossmeier <greg(a)wikimedia.org>
>> wrote:
>> > Adding wikitech-l
>> >
>> > On Mon, Dec 1, 2014 at 2:59 PM, Greg Grossmeier <greg(a)wikimedia.org>
>> > wrote:
>> >> tl;dr: Testing on deployment-salt (or other Beta
>> >> Cluster/deployment-prep vms?): please watch out for "[LOCAL HACK]"
>> >> commits and don't lose them.
>> >>
>> >>
>> >> See:
>> >> https://phabricator.wikimedia.org/T75947
>> >>
>> >> Basically: Some local puppet changes were committed on deployment-salt
>> >> with "[LOCAL HACK]" in the summary (as is the practice to test/do
>> >> things before they're merged in ops/puppet for a number of reasons,
>> >> see: https://phabricator.wikimedia.org/T76392 for reducing that). They
>> >> were, unfortunately lost somehow. Current theory is that someone
>> >> accidentally clobbered them while doing their own testing.
>> >>
>> >> If it was you, no worries (Bryan's already fixed this specific case,
>> >> thanks Bryan!) but please don't do it again. :)
>> >>
>> >> Feel free to talk with the QA mailing list if you have any questions
>> >> on how to do testing of puppet changes in Beta Cluster:
>> >> https://lists.wikimedia.org/mailman/listinfo/qa
>> >>
>> >> Best,
>> >>
>> >> Greg
>>
>> On any given day there are generally quite a few cherry-picked commits
>> on deployment-salt that are being tested and used in the beta cluster
>> prior to being merged into the shared operations/puppet.git repo that
>> powers puppet for labs in general, the beta project (deployment-prep)
>> and our production hosts. At the moment I'm writing this, the list
>> looks like this:
>>
>> deployment-salt:/var/lib/git/operations/puppet (git production $)
>> bd808$ git log --color --pretty=oneline --abbrev-commit origin/HEAD..HEAD
>> 3353137 logstash: Forward syslog events for apache2 + hhvm
>> ace40a2 Use hiera to configure udp2log endpoint for ::mediawiki
>> dc11da3 logstash: Rules for processing MW input via Redis
>> 22837cd Configure Logstash and Elasticsearch for ApiFeatureUsage
>> 53d8b58 Change eventlogging log dir
>> bbaa10b eventlogging: couple less tightly to ganglia
>> 48f60fa Fix Parsoid in beta
>> 1d58f04 Get betalabs localsettings.js file from deploy repo (just like
>> prod)
>> 4e03e67 Allow puppetmaster to send reports to logstash
>> caef989 [LOCAL HACK] T67591: User['mwdeploy'] shell => /bin/bash
>> a22bbec [LOCAL HACK] T47706 Change MySQL admin user in sql script
>>
>> There is a pretty good write up on wikitech [0] on the safe process
>> for adding a new cherry-pick to the beta puppet master and removing
>> one that is no longer wanted. I'd be glad to help anyone who has
>> questions or problems with the process as well.
>>
>> [0]:
>> https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/How_code_…
>>
>> Bryan
>> --
>> Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
>> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
>> irc: bd808 v:415.839.6885 x6855
>>
>> _______________________________________________
>> Engineering mailing list
>> Engineering(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This
major release removes deprecated functionality. Please migrate away from this
deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package
that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple
of years ago due to lack of time and concern about disruption. Because of this,
many developers have needed to work around bugs that were already fixed in later
versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been
the first release in jQuery history that needed an upgrade guide[1][2]. It's a
major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts
should be trivial (swapping one method for another, maybe with a slight change
to the parameters passed). This is all documented in the upgrade guide[1][2].
The upgrade guide may look scary (as it lists many of your favourite methods),
but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
1) Get familiar with http://jquery.com/upgrade-guide/1.9/.
2) Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is
already present in jQuery 1.8 or, in some cases, earlier.
3) Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation
warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also
find deprecation notices from mediawiki.js, for more about those see the mail
from last October [8].
== Plan ==
1) Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will
need work. I have started work on loading jQuery Migrate alongside the current
version of jQuery. I expect that to land in master this week [6], and roll out on
Wikimedia wikis the week after. This will enable you to detect usage of most
deprecated functionality through your browser console. Don't forget the upgrade
guide[1], as Migrate cannot detect everything.
2) Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This
should not break anything since Migrate covers almost all functionality that
will be removed. The instrumentation and logging will remain during this phase;
the only effective change at this point is whatever jQuery didn't think was
worth covering in Migrate or were just one of many bug fixes.
3) Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility
layer and its instrumentation). This will bring us to a clean version of latest
jQuery v1.x without compatibility hacks.
A rough timeline:
* 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
will run for 4 weeks (until June 9).
* 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
weeks (upto June 9). The instrumentation continues during this period.
* 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking
enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any
hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not
all, consult the upgrade guide[2] for details). It also logs usage of these to
the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low.
An update will be sent to wikitech-l just before this is done as a final reminder.
This will be well before the MediaWiki 1.24 branch point for extension authors
looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x
doesn't contain any new features compared to jQuery v1 [3]. The main difference
is in the reduced support for different browsers and environments; most
noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which
MediaWiki is still supporting for now, and is outside the scope of this work.
Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new
features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
final-released/
[2] http://jquery.com/upgrade-guide/1.9/
[3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/
[4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
[5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/
[6] https://gerrit.wikimedia.org/r/131494
[7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md
[8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html
[9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
Adding wikitech-l
On Mon, Dec 1, 2014 at 2:59 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> tl;dr: Testing on deployment-salt (or other Beta
> Cluster/deployment-prep vms?): please watch out for "[LOCAL HACK]"
> commits and don't lose them.
>
>
> See:
> https://phabricator.wikimedia.org/T75947
>
> Basically: Some local puppet changes were committed on deployment-salt
> with "[LOCAL HACK]" in the summary (as is the practice to test/do
> things before they're merged in ops/puppet for a number of reasons,
> see: https://phabricator.wikimedia.org/T76392 for reducing that). They
> were, unfortunately lost somehow. Current theory is that someone
> accidentally clobbered them while doing their own testing.
>
> If it was you, no worries (Bryan's already fixed this specific case,
> thanks Bryan!) but please don't do it again. :)
>
> Feel free to talk with the QA mailing list if you have any questions
> on how to do testing of puppet changes in Beta Cluster:
> https://lists.wikimedia.org/mailman/listinfo/qa
>
> Best,
>
> Greg
>
> --
> Greg Grossmeier
> Release Team Manager
--
Greg Grossmeier
Release Team Manager
The original request behind Scribunto's mw.text.unstrip method was to undo
<nowiki> tags, as a mechanism for quoting arguments being passed into a
module. But the implementation was more broad, allowing access to the HTML
generated by the <ref> and <references> tags, by special page transclusion,
and so on. This caused problems such as T63268.[1]
With the merge of Gerrit change 171290,[2] the mw.text.unstrip method will
unstrip nowiki strip markers and will replace all other strip markers with
the empty string. A new method mw.text.unstripNoWiki is also provided to
unstrip nowiki markers while leaving other markers in place, and
mw.text.killMarkers to remove all strip markers from a string.
Modules using mw.text.unstrip should be checked to ensure they don't break
with this change. A list of modules on WMF wikis including the string
"unstrip" is at https://test.wikipedia.org/wiki/User:Jackmcbarn/unstrip.
See https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the
deployment schedule.
[1]: https://phabricator.wikimedia.org/T63268
[2]: https://gerrit.wikimedia.org/r/#/c/171290/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
