Hello all,
I just wanted to send a note about a reference doc on the MediaWiki
wiki on backporting bug fixes:
https://www.mediawiki.org/wiki/Backporting_Fixes
It addresses the difference between backports to stable releases versus
the code on the WMF cluster (as well as the special process for security
related bugs).
Of note:
We now have backport "flags" in bugzilla to track the backport
process. There is one for stable releases ("Backport_to_Stable") and
one for the WMF cluster ("Backport_WMF").
I hope this can help to clarify some confusion around the backporting
process.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi
I am trying to fix bug 48489 - Can not paste new link anchor for VisualEditor.
https://bugzilla.wikimedia.org/show_bug.cgi?id=48489
I have been able to add the functionality to the link inspector to
edit the displayed text.
https://gerrit.wikimedia.org/r/#/c/64055/
I have not worked on the appearance of the interface. What user
interface the community would like to get?
Which existing widgets if any should be included when adding this
functionality? (currently just using InputWidget.js)
Cheers,
Jiabao
Hello!
As many of you know, the Wikimedia Foundation is now actively engaged in designing a next-generation discussion and workflow system called Flow, initially slated to replace user talk pages. Flow is an ambitious project (on par with the VisualEditor) and will touch nearly every aspect of the Wikimedia experience.
We need ''your'' help and input. We have started a portal for information and discussion.
You can find it on the English Wikipedia here: http://en.wikipedia.org/wiki/Wikipedia:Flow
And on MediaWiki here: http://www.mediawiki.org/wiki/Flow_Portal
(We'll be creating one on meta as well).
At the Flow portal, you can read about what we're doing and why, as well as play around with an interactive prototype.
We're desperately interested in your feedback and thoughts. There are things that we know, and things that we know that we don't know. But there are also things that we *don't* know that we don't know. And we want to reduce that lack of knowledge.
We will also be conducting additional office hours for a variety of timezones - as many as we need to - and will also be open to having conversations via Google hangouts and/or Skype as need be. I am always around on irc (freenode, username "jorm") and am willing to answer any questions you may have.
-b.
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi, I've seen recently a lot of code like this:
$html = Html::openElement( 'div', array( 'class' => 'foo' )
. Html::rawElement( 'p', array(),
Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ),
$somePotentiallyUnsafeText
)
)
. Html::closeElement( 'div' );
IMO, cruft like this makes things harder to read and adds additional
performance overhead. It can be simplified to
$html = '<div class="foo'><p>'
. Html::rawElement( 'p', array(),
Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId ),
$somePotentiallyUnsafeText
)
)
. '</p></div>';
What's your opinion, guys and gals?
--
Best regards,
Max Semenik ([[User:MaxSem]])
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 |