In putting together the tarball for 1.20, I had some trouble with
creating an announcement for the release that captured the really
significant changes that third party users of MediaWiki should know
about. I hope that I can work with the developers to make this
announcement for 1.21 more informative while remaining concise.
Yes, we have the RELEASE-NOTES file, but this is really too big to be
easily comprehended by the average user of MediaWiki and it is too big
for me to scan and synthesize in the limited amount of time that I have.
I'd like to find a way to come up with something like
<https://www.mediawiki.org/wiki/MediaWiki_1.18> for every release. Or,
at least better than what we currently have at
<https://www.mediawiki.org/wiki/MediaWiki_1.20>.
At the same time, I don't want to impose an onerous burden on
developers, so I'd like to figure out how to keep the the MediaWiki_1.21
page up to date as we go along.
One idea I had was scanning the changes in RELEASE-NOTES on a, say,
weekly basis and updating the current MediaWiki_X.xx page.
Another was asking code reviewers to somehow flag commits in Gerrit as a
signal for a volunteer (like me) to add it to the current MediaWiki_X.xx
page: "Hey! this really should get more attention."
But these are just my ideas right now. I'm open to suggestions for how
to improve the release process for MediaWiki.
(Oh, and if you know of something that the average user of MediaWiki
should really know, but that isn't yet included on
<https://www.mediawiki.org/wiki/MediaWiki_1.20>, then, please, update
the page.)
--
http://hexmode.com/
Any time you have "one overriding idea", and push your idea as a
superior ideology, you're going to be wrong. ... The fact is,
reality is complicated -- Linus Torvalds <http://hexm.de/mc>
Hi,
in case that you are a heavy user of bugzilla.wikimedia.org and triage /
comment on many reports:
I've shared my hackish Greasemonkey scripts (that's clientside
Javascript that runs in Firefox and some other browsers).
These scripts include stuff like
* provide one-click stock comments,
* embed several links (to Extension product homepage;
query tickets previously filed by the reporter)
* display email addresses of people and not just the name
* color people based on a manual list (e.g. green = "I know
this person and don't need to look at this report")
* color MWExtensions based on a manual list (e.g. "green = deployed")
etc.
Obviously the code could be improved but it "works for me":
https://gerrit.wikimedia.org/r/gitweb?p=wikimedia/bugzilla/triagescripts.gi…
Feedback and contributions welcome.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
The fact that mediawiki's repository is named "mediawiki-core" doesn't make sense to me. The chief benefit provided by GitHub is its popularity and visibility. We don't manage our code review or release process in GitHub anyway, so I see no reason not to give the most weight to aesthetic / populistic considerations. Let's make it github.com/wikimedia/mediawiki. Visibility helps!
--
Ori Livneh
ori(a)wikimedia.org
Hi everyone,
Time once again for our weekly tech chat. Rather, Thursday is the
time, because this week, I'm giving you *two whole days*[1] instead of
the whopping hour notice that I gave you all last week.
Full details here:
https://www.mediawiki.org/wiki/Meetings/2012-11-15
For those too lazy to click, here are the essentials:
* When: Thursday, 12:30pm PST (20:30 UTC)
* Where: 6th floor + #wikimedia-dev + Google Hangout + YouTube
This week, we have Saper presenting about Git and Gerrit tricks.
Hope to see you there!
Rob
[1] Alright, technically, it's a little less than 44 hours, but that's
still a lot better than last week, right? right?!?
jHi all,
a reminder to chapters and volunteers around the world -- if you're
planning a hackathon, please let us know beforehand by adding it to
this page:
https://www.mediawiki.org/wiki/MediaWiki_developer_meetings
Consistent with Sue's recommendations to the Board, Wikimedia
Foundation will spend less time organizing events on its own, and will
more frequently send smaller groups to events organized around the
world by the movement at large. But to do so we need to know what's
coming up. :)
Hackathons/DevCamps are a great way to help the movement. They can
engage the existing volunteer developer commmunity, help expand it,
bring together engineers with other Wikimedia practitioners, and
create a focused space. We hope more folks around the world will take
a role in hosting such developer events. If you would like WMF's
thoughts and input, please feel free to ping Sumana (sumanah at
wikimedia.org).
All the best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hi,
At https://gerrit.wikimedia.org/r/#/c/33163/ TheDJ commented that I
should have updated the release notes.
At another commit I made once (forgot which one) somebody commented
that I shouldn't have updated the release notes and that this should
only be done by the release manager, because this helps avoid merge
conflicts and because the release manager has better judgment about
which issues are important enough to be mentioned there.
So should I or shouldn't I update them?
I remember a couple of attempts to discuss it, but I don't remember a decision.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I was a bit of a lazy child, specially when it came to clean up my room
or do my homework. I tried to convince my mom and teachers about the
paradigm of RESOLVED LATER, but they never bought it. At the end I had
to clean up my room and do my homework.
Even as a child I suspected that they were actually right. If something
has been postponed for later it can't be called "resolved". Now it's me
who hears from time to time excuses from my kids that sound more or less
like RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source
of pending work. :)
And now to the topic:
What about removing the LATER resolution from our Bugzilla? It feels
like sweeping reports under the carpet. If a team is convinced that
something won't be addressed any time soon then they can WONTFIX. If
anybody feels differently then they can take the report back and fix it.
Before we could simply reopen the 311 reports filed under RESOLVED LATER:
http://bit.ly/YxW60z
Huggle 1
MediaWiki 74
MediaWiki extensions 104
Monuments database 1
mwEmbed 3
Parsoid 1
Tools 2
WikiLoves Monuments Mobile 4
Wikimedia 114
Wikimedia Labs 1
Wikimedia Mobile 3
Wikipedia App 3
Total 311
Looking at the total amount of open bugs, the impact is not that big.
The house will be as tidy/untidy as before, but at least things wll be
clearer now.
What do you think?
--
Quim
Hi,
In the Bangalore DevCamp I worked with Aditya Ravi Shankar on
resolving Bug 35038 - Make MathJax menus translatable. It was mostly a
success, but where should we commit the changes? Somewhat
surprisingly, most of the changes will be needed in the MediaWiki
extension code and not in the upstream library's repo. But apparently,
the MathJax extension is not in Gerrit - its files must be downloaded
from an obscure external site.
Is there any reason not to setup a Gerrit extension for it?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi.
There's an entry in Wikimedia's engineering goals page[1] that reads "Full
production switch-over of EQIAD as primary DC, Tampa as secondary; test
failover capabilities." It's targeted for October to December 2012. I'm
wondering what the status of that switchover is.
I looked at the relevant Wikitech wiki page.[2] I didn't gain much insight.
I also looked at mediawiki.org, but was only able to find an outdated
page.[3]
With some poking, I found another page on the Wikitech wiki about a planned
migration. It reads "Identify and plan around the deployment/migration date
- tentatively Oct 15, 2012. Need to communicate date."[4]
I searched the Wikimedia blog for "eqiad"[5] and there are a few mentions of
the new data center being used for particular tasks in the monthly
engineering reports, but I'm not sure if it was ever switched to be the
primary data center. Was it? If not, has that switchover been rescheduled?
MZMcBride
[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals
[2] http://wikitech.wikimedia.org/view/Ashburn_cluster
[3] https://www.mediawiki.org/wiki/WMF_Projects/Data_Center_Virginia
[4] http://wikitech.wikimedia.org/view/Eqiad_Migration_Planning
[5] https://blog.wikimedia.org/?s=eqiad
Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set
some tag in bugzilla. At some point somebody approves and merges the
patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much remembering involved for my taste. It's easy to
forget to close the bug in bugzilla, especially if the patch has been
lying around for some time before being merged.
Would it be possible/sensible to automatically close a bug when the
patch is merged? Or did I miss something?
Cheers,
Stephan