Hey all,
We've posted our proposal for the release management RFP. You can find
it at https://www.mediawiki.org/wiki/Release_Management_RFP/2014/Consortium
Our team includes me (Kim Schoonover), Ryan Schmidt (Skizzerz), Benjamin
Lees (Emufarmers), Jack Phoenix, and Bartosz Dziewoński (Matma Rex). We
are a consortium of developers and system administrators who maintain,
support and develop for large MediaWiki installations serving thousands
of users. We think we know a thing or two about what MediaWiki releases
need.
Please comment; your feedback is welcome and needed to make this a success.
-Isarra
Hello everyone,
Mark Hershberger and I submitted a proposal for the next year of release management:
https://www.mediawiki.org/wiki/Release_Management_RFP/2014/Mark_y_Markus_LLC
In the upcoming year, we want to focus on creating a user group as a central hub for all third party related issues with MediaWiki.
We are happy to hear your comments, feedback and ideas.
Best,
Markus
(mglaser)
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_16th>
A quick list of notable items...
== Tuesday ==
* MediaWiki deploy
** group1 to 1.24wmf9: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf9>
* Mobile view
** Tablets will be sent to the mobile version of the project
websites. Previously they were sent to the desktop version. There is
a blog post and central notice drafted and ready to go out day of.
* CentralAuth Global Rename Tool
** CentralAuth will now provide an interface to rename global users.
** More info at: <https://www.mediawiki.org/wiki/Help:Extension:CentralAuth/Global_rename>
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf9 (all Wikipedias)
** group0 to 1.24wmf10 (test/test2/testwikidata/mediawiki)
* MediaViewer
** Will be enabled on *all* wikis
** <https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Timeline>
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Changesets that could still use your attention:
* Add a PSR-3 based logging interface
https://gerrit.wikimedia.org/r/#/c/119940/
* Enable MWLogger logging for wfLogProfilingData
https://gerrit.wikimedia.org/r/#/c/119942/
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
On Fri, Apr 11, 2014 at 11:38 AM, Bryan Davis <bd808(a)wikimedia.org> wrote:
> On Fri, Mar 14, 2014 at 4:07 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:
> > The structured logging RFC [0] will be up for discussion again next
> > Wednesday [1]. There is a strawman implementation in gerrit [2] that
> > is likely to be the focus of discussion unless there are other issues
> > that the reviewers find more pressing.
> >
> > At this point the most controversial aspect of my proposed
> > implementation seems to be importing third-party libraries into
> > mw-core and/or the use of composer to manage that activity. I would
> > welcome discussion of alternatives or consensus that this is a
> > reasonable approach for the immediate future that should be revisited
> > if and when a better idea is found for the general problem.
> >
> > [0]:
> https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging
> > [1]:
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-19
> > [2]: https://gerrit.wikimedia.org/r/#/c/112699/
>
> The outcome of the discussion on this was approval by Tim of the
> general concept of using Composer to manage importing libraries into
> MediaWiki-Core. I took that as incentive to split the monolithic
> proof-of-concept patch into four smaller logical for review and
> approval:
>
> * Gerrit change 119939 Add Composer managed libraries [3]
>
> Import Psr\Log and Monolog libraries to MW-Core in a new "libs"
> directory which is managed using Composer. The includes/AutoLoader.php
> script has been modified to require the lib/autoload.php class
> autoloader script generated by Composer.
>
> * Gerrit change 119940 Add a PSR-3 based logging interface [4]
>
> The MWLogger class is actually a thin wrapper around any PSR-3
> LoggerInterface implementation. Named MWLogger instances can be
> obtained from the MWLogger::getInstance() static method. MWLogger
> expects a class implementing the MWLoggerSpi interface to act as a
> factory for new MWLogger instances. A concrete MWLoggerSpi
> implementation using the Monolog library is also provided.
>
> * Gerrit change 119941 Enable MWLogger logging for legacy logging methods
> [5]
>
> Introduces the $wgUseMWLoggerForLegacyFunctions that enables the use
> of the MWLogger PSR-3 logger for legacy global logging functions. When
> enabled wfDebug, wfDebugLog and wfLogDBError will route their log
> messages to MWLogger instances.
>
> * Gerrit change 119942 Enable MWLogger logging for wfLogProfilingData [6]
>
> Output structured profiling report data from wfLogProfilingData when
> $wgUseMWLoggerForLegacyFunctions is enabled.
>
> I got some great review feedback from Jeroen on the first patch [3].
> We were able to iterate to get to a point where he was satisfied with
> the technical implementation of the composer.json and gave it a +1.
> The second patch [4] got some comments from Tyler and Timo which I
> have tried to respond to. Tyler caught a small formatting problem in
> the third patch [5] that has been corrected. I have gotten no feedback
> at all on the final patch [6].
>
> I'd really like to see this work merged so that I can continue to
> build on it to improve the error and debug logging capabilities of
> MediaWiki. The net result if this was all merged today would be some
> classes that could be used if a deployment modified it's
> LocalSettings.php configuration to enable them. Nothing should break
> anywhere in the default case. I know that most people don't find
> logging to be sexy stuff to think about and that I'm weird for being
> obsessed with this sort of thing. I'm looking for advice from the
> people on this mailing list on how to find someone to work with me to
> finish the review of at least the first 3 patches and give +2 to get
> this initiative moving again.
>
> [3]: https://gerrit.wikimedia.org/r/119939
> [4]: https://gerrit.wikimedia.org/r/119940
> [5]: https://gerrit.wikimedia.org/r/119941
> [6]: https://gerrit.wikimedia.org/r/119942
>
> 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
>
> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
>
Has anyone had success with this...?
This is what happens when I try to run:
master x ~/git/vagrant/mediawiki/tests/phpunit $ php phpunit.php
Warning: require_once(/vagrant/LocalSettings.php): failed to open
stream: No such file or directory in
/Users/jrobson/git/vagrant/mediawiki/LocalSettings.php on line 130
Fatal error: require_once(): Failed opening required
'/vagrant/LocalSettings.php' (include_path='.:') in
/Users/jrobson/git/vagrant/mediawiki/LocalSettings.php on line 130
Thanks for the chat just now
https://www.mediawiki.org/wiki/Architecture_meetings/Security_guidelines_di…
- summary and full logs are up. Chris now has several TODOs to improve
the draft, including maybe splitting out some details onto other pages.
For each of the security principles, we need good and bad past examples
of what Wikimedia/MediaWiki has done. Where we've succeeded, where we've
fallen down. Chris has assembled several, but:
* we still need a past example of how Wikimedia (doesn't HAVE to be
MediaWiki specifically) screwed up on "Secure (fail-safe) defaults" --
hopefully we've since fixed it!
* we still need a positive example of where we've created a simple
design, implementation, or interface whose simplicity guards against
future errors or attacks. Suggestion: "HTMLForm, while incredibly
complex, has a relatively simple interface for security, i.e., built-in
CSRF tokens and validation."
If you can, comment on the talkpage:
https://www.mediawiki.org/wiki/Talk:Security_for_developers/Architecture
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
I've addressed the feedback I got in Zurich.
https://www.mediawiki.org/wiki/Performance_guidelines
I think this page is ready to have the {{draft}} tag removed. I believe
it now represents our consensus on what MediaWiki core, extensions, and
gadgets developers should do to preserve high performance. On May 23,
I'd like to move forward with making a tutorial and a poster based on
this. So, please edit, speak up, and so on, within the next week.
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
We discussed a few RfCs yesterday:
* Making a user right for using the debugging toolbar
http://www.mediawiki.org/wiki/Debugging_toolbar : at least some people
are interested in turning this on in Wikimedia-world, such as beta.
Author devunt will outline security implications and reach out to Chris
Steipp.
* Reducing image quality for mobile: it's agreed to do PHP-side
modification for low-quality images on zero, splitting cache in Varnish.
JS is not suitable. Adam Baso's leading a gradual rollout to gather data
for testing; see notes for details.
* HTML templating library: Jon Robson will ask Juliusz, Maryana, Arthur,
et alia to schedule time for the Mobile team to give KnockOff /
TAssembly a spin.
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-11
Reminder: 1500 UTC Friday (today/tomorrow), we discuss the security
guidelines:
https://www.mediawiki.org/wiki/Architecture_meetings/Security_guidelines_di…
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or preferably by
running composer to obtain dependencies.
I have suggested, as a compromise, to make the vendor directory be a
submodule pointing to mediawiki/core/vendor. Then users can either run
"git submodule update --init" to obtain dependencies, or they can omit
submodule initialisation and instead run composer.
I would like to hear more comments on this.
-- Tim Starling