Hello,
yesterday I found myself with a problem similar to the one described here:
http://stackoverflow.com/questions/15164710/mediawiki-templates-inherit-par…
But, actually, I would like to process template paramaters without first
having to return the values associated to them -> {{{param1}}},
{{{param2}}}. Let's say, something like processing argv, where argv may
contain argv['param1'], argv['param2'], but not knowing whether param1
or param2 do exist first (I should iterate over keys in this case…)
Is this something that might be done somehow by using Lula (Scribunto)?
Thanks!
--
Toni Hermoso Pulido
http://www.cau.cat
https://wikitech.wikimedia.org/wiki/Deployments/One_week
[tl;dr] My recommendation for us to switch to a one-week deploy is to
use Robla's suggestion (Option B on the wiki page[0]) starting on Monday
June 10th. This will coincide with the start of the MediaWiki 1.22wmf6
deployment on WMF servers.
Unless there are any major concerns with this proposal, I'll start
modifying the relevant parts of the wiki (mostly
https://wikitech.wikimedia.org/wiki/Deployments and
https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…
).
== Riding the Train ==
Now is the time to start getting more development teams to start riding
the MW Core deploy train. If a one-week cycle/14 day lifespan (with the
always possible important backports available) is something doable for
your team right now, please do let me know. If it isn't, please let me
know what would be "good enough". Would Option A have been?
== Reasoning for Option B ==
Although we strive to be a continuous integration and deployment house,
we aren't quite there yet. With that in mind, having the space between
deploying to test/test2/mediawiki.org and the non-WP project sites is
beneficial.
Possible workarounds to this problem included having two deploy windows
on Monday (in the Option A version); one for test/test2/mediawiki in the
morning, with a few hours gap then one for all non-WP project sites. The
gap would be used for both automated and manual tests. While the
automated tests could be scheduled and completed in a reasonable time
frame, counting on the QA team to complete manual tests and report bugs
in a small window isn't a dependency we should have right now; manual
tests still catch a lot of issues that the automated ones do not.
Going with Option B does already reduce our wmfXX branch lifespan from
24 days to 14 days. "Lifespan" being the number of days that any branch
is live on any wiki (from the day it goes to test/test2/mediawiki to the
day its "slot" is replaced with a new wmfXX branch). Limiting our
testing time to get down to 10 days doesn't seem worth it yet.
== Future ==
To get us down to a quicker cycle (lifespan of 10 or fewer days) we'll
need to do a bit more work on the QA/testing side of things (which
involves everything from betalabs, to test/test2, to unit tests, to
selenium, et al). We're on the right path, thankfully.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello all,
Let's move our MediaWiki deploy cycle to weekly instead of 2-week.
This will also reduce the number of standing deployment windows
throughout the week by having those projects/teams simply "ride the
MediaWiki train."
== Current situation ==
Right now, a new version of MediaWiki is rolled out to the WMF cluster
over a two-week period. You can see the general flow of how it works on
this page describing the deploy schedule for the 1.22 release:
https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…
== What are the drawbacks of two-weeks? ==
These are mostly known by everyone so I'll just simply state the most
obvious one :-)
It takes up to 2 weeks for new features/bug fixes to be rolled out to
the various Wikimedia wikis.
== What would a one-week cycle look like? ==
This has been talked about a bit, including during the last In Town Week
for WMF Engineering in late-February. I've coalesced on one proposal at:
https://wikitech.wikimedia.org/wiki/Deployments/One_week
This seems like a reasonable approach to me. Please respond here or on
the talk page with comments/suggestions/etc.
== Major benefit/goal with one-week cycle ==
Our current list of deployment windows during the week is pretty large,
and it is not uncommon for a week to practically fill up with bug fix
windows. If we moved to a weekly cycle then more of those bug-fixes
could just roll out with the normal MediaWiki deploy.
== Goal Timeline? ==
I would love to get us switched over to a one-week cycle by mid-June.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi,
Since there appears to have been a little bit of trivia around fixing
these phpcs warnings, I'll open a thread instead.
Both in javascript and PHP there are various keywords that can be used
as if they are functions. In my opinion this is a misuse of the
language and only causes confusion.
I'm referring to code like this (both javascript and php):
delete( mw.legacy );
new( mw.Title );
typeof( mw );
echo( $foo . $bar );
print( $foo . $bar );
return( $foo . $bar );
… and, wait for it..
require_once( $foo . $bar );
I think most experienced javascript developers know by now that using
"delete" or "new" like it is a function is just silly and looks like
you don't know what you're doing.
To give a bit of background, here's why these work at all (they aren't
implemented both keywords and functions, just keywords). Though I'm
sure the implementation details differ between PHP and javascript, the
end result is the same: Keywords are given expressions which are then
evaluated and the result is used as value. Since expressions can be
wrapped in parenthesis for readability (or logic grouping), and since
whitespace is insignificant to the interpreter, it is possible to do
`return("test")`, which really is just `return ("test")` and
eventually `return "test"`.
I'm obviously biased, but I think the same goes for "require_once"
(and "include", "require" etc.). Right now this is causing quite a few
warnings in our php-checkstyle report.
I didn't disable that rule because it appears (using our code base as
status quo) that we do want this. There's 0 warnings I could find in
our code base that violate this, except for when the keyword is
include|require(_once)?
The check style sniffer does not (and imho should not) have a separate
rule per keyword. Either you use constructs like this, or you don't.
But let's not have some weird exception just because someone didn't
understand it[1] and we all copied it and want to keep it for no
rational reason.
Because that would mean we have to either hack the sniffer to exclude
this somehow, or we need to disable the rule, thus not catching the
ones we do use.
See pending change in gerrit that does a quick pass of (most of) these
in mediawiki/core:
https://gerrit.wikimedia.org/r/62753
-- Krinkle
[1] Or whatever the reason is the author originally wrote it like
this. Perhaps PHP was different back then, or perhaps there was a
different coding style.
for the Score extension it would be nice to output SVG images, the SVG
images produced by lilypond have lots of white space (it outputs paper
sheets), covert can give the outer bound and offset of the area we want to
display:
I.e. for http://upload.wikimedia.org/wikipedia/test2/d/d5/ScoreSVGTest.svg
$ convert ScoreSVGTest.svg -trim info:-
ScoreSVGTest.svg SVG 434x267 744x1052+27+23 16-bit DirectClass 0.010u
0:00.009
If SVG is scaled to 744x1052, we want to crop it to 434x267 starting at
(27, 23)
Does anyone know how to translate this into the width/height/viewBox
properties in SVG?
Andre reminded me that there is a problem with upgrading the job queues
that have any items in them In https://bugzilla.wikimedia.org/46934.
I would like to include a warning in the installation documentation to
clear your job queue before the upgrade, but I don't know that much
about the job queue in MW or even if this is possible.
Are there any recommendations for what to tell users?
--
http://hexmode.com/
Imagination does not breed insanity. Exactly what does breed insanity
is reason. Poets do not go mad; but chess-players do.
-- G.K. Chesterson
Hi,
Long time ago when I started learning with git I decided to create a
simple guide (basically I was just taking some notes of what is
needed). I never thought that it could be useful to anyone so I never
announced it anywhere. However I got some feedback to it, so I decided
to inform you too.
The basic idea is to create a TOTALLY SIMPLE guide that git
illiterates like me can understand and thanks to which they would find
out how to do stuff in wikimedia git / gerrit.
Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It doesn't contain so much and there are some mistakes / feel free to fix them.
Since wikimedia switched to gerrit from svn I have yet met a tons of
people who had problems adapting to it, so this could eventually help
some.
Recently a lot of people have been talking about what's possible and
what's necessary regarding MediaWiki, CatScan-like tools, and real
category intersection; this mail has some pointers.
The long-term solution is a sparkly query for, e.g., people with aspects
novelist + Singaporean, and it would be great if Wikidata could be the
data-source. Generally people don't really want to search using
hierarchical categories; they want tags and they want AND. But
MediaWiki's current power users do use hierarchical labels, so any
change would have to deal with current users' expectations. Also my
head hurts just thinking of the "but my intuitively obvious ontology is
better than yours" arguments.
Conversations have been a bit scattered:
https://meta.wikimedia.org/wiki/Beyond_categorieshttp://lists.wikimedia.org/pipermail/wikidata-l/2013-May/thread.html#2202 ("Question
about wikipedia categories.")
https://en.wikipedia.org/wiki/Wikipedia_talk:Category_intersection#A_workin…
CatScan, which can find articles in category intersections:
https://en.wikipedia.org/wiki/Wikipedia:CatScanhttp://lists.wikimedia.org/pipermail/gendergap/2013-April/003552.htmlhttps://bugzilla.wikimedia.org/show_bug.cgi?id=5244 "Allow searching in
intersections, etc. of categories"
I think the best place to pursue this topic is probably in
https://meta.wikimedia.org/wiki/Talk:Beyond_categories . It's unlikely
Wikimedia Foundation will be able to make engineers available to work on
this anytime soon, but I would not be surprised if the Wikidata
developer community or volunteers found this interesting enough to work on.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
hi-
i'm hopeful this is the appropriate venue for this topic - i recently
had occasion to visit #mediawiki on freenode, looking for help. i found
myself a bit frustrated by the amount of bot activity there and wondered
if there might be value in some consideration for this. it seems to
frequently drown out/dilute those asking for help, which can be a bit
discouraging/frustrating. additionally, from the perspective of those
who might help [based on my experience in this role in other channels],
constant activity can sometimes engender disinterest [e.g. the irc
client shows activity in the channel, but i'm less inclined to look as
it's probably just a bot].
to offer one possibility - i know there are a number of mediawiki and/or
wikimedia related channels - might there be one in which bot activity
might be better suited, in the context of less contention between the
two audiences [those seeking help vs. those interested in development,
etc]? one nomenclature convention that seems to be at least somewhat of
a defacto standard is #project for general help, and #project-dev[el]
for development topics. a few examples of this i've seen are android,
libreoffice, python, and asterisk. adding yet another channel to this
list might not be terribly welcome, but maybe the distinction would be
worth the addition?
as i'm writing this, i see another thread has begun wrt freenode, and i
also see a bug filed that relates at least to some degree
[https://bugzilla.wikimedia.org/show_bug.cgi?id=35427], so i may just be
repeating an existing sentiment, but i wanted to at least offer a brief
perspective.
regards
-ben
