I had a useful conversation about Puppet changes with Mark and Faidon. The
outcome is this: the conditions under which I am allowed to merge Puppet
changes are:
1) The change is my own
2) The change has been +1'd by an ops team member with sufficient domain
expertise
Sometimes you guys add me as the sole reviewer of small Puppet changes.
Please be aware that I am not able to merge those changes on my own, and
help me out by adding some relevant opsen. Giuseppe (_joe_ on irc) is my
buddy for mediawiki-related changes so he's a good person to add. Adding
whomever is on RT duty is probably a good idea as well. You can still add
me for initial review and +1 / -1.
I thought I'd start this discussion in earnest here on the mw-core
list and then take it to a larger list if needed once we have a
reasonable plan.
My logging changes [0][1][2][3] are getting closer to being mergeable
(the first has already been merged). Tony Thomas' Swift Mailer change
[4] is also progressing. Both sets of changes introduce the concept of
specifying external library dependencies, both required and suggested,
to mediawiki/core.git via composer.json. Composer can be used by
people directly consuming the git repository to install and manage
these dependencies. I gave a example set of usage instructions in the
commit message for my patch that introduced the dependency on PSR-3
[0]. In the production cluster, on Jenkins job runners and in the
tarball releases prepared by M&M we will want a different solution.
My idea of how to deal with this is to create a new gerrit repository
(mediawiki/core/vendor.git?) that contains a composer.json file
similar to the one I had in patch set 7 of my first logging patch [5].
This composer.json file would be used to tell Composer the exact
versions of libraries to download. Someone would manually run Composer
in a checkout of this repository and then commit the downloaded
content, composer.lock file and generated autoloader.php to the
repository for review. We would then be able to branch and use this
repository as git submodule in the wmf/1.2XwmfY branches that are
deployed to production and ensure that it is checked out along with
mw-core on the Jenkins nodes. By placing this submodule at $IP/vendor
in mw-core we would be mimicking the configuration that direct users
of Composer will experience. WebStart.php already includes
$IP/vendor/autoload.php when present so integration with the rest of
wm-core should follow from that. It would also be possible for M&M to
add this repo to their tarballs for distribution.
I think Ori has a slightly different idea about how to approach this
issue. I'd like to hear his idea in this thread and then reach
consensus on how to move forward here or take both ideas (and any
other credible alternatives) to a large list for a final decision.
[0]: https://gerrit.wikimedia.org/r/#/c/119939/
[1]: https://gerrit.wikimedia.org/r/#/c/119940/
[2]: https://gerrit.wikimedia.org/r/#/c/119941/
[3]: https://gerrit.wikimedia.org/r/#/c/119942/
[4]: https://gerrit.wikimedia.org/r/#/c/135290/
[5]: https://gerrit.wikimedia.org/r/#/c/119939/7/libs/composer.json,unified
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
Hi folks,
Tim, Ori and I got together yesterday and then, from our raw notes, I've
added a few things to our idea backlog. My cleanup may not be entirely
faithful to our conversation, so bear that in mind as you read this. I've
included the relevant bits below for convenience, but it's also available
here:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Backlog
Rob
Installation consolidation
Aligning MediaWiki developer and third party installation methods. Easy
install of more complicated MediaWiki installs (e.g. Parsoid, PDF
rendering, Math, etc). Possible use of Vagrant-Composer?
-
- https://developers.google.com/compute/docs/containers
-
- Composer package types:
- https://github.com/composer/installers
- there exists a very nominal 'mediawiki-extension' type:
https://github.com/composer/installers/blob/master/src/Composer/Installers/…
- https://bugzilla.wikimedia.org/show_bug.cgi?id=65188#c3
-
- Assess viability of deploying MediaWiki using Containers to both
the production cluster and various cloud platforms
- ...as a way of improving our internal deployment process
- ...as a way of making MediaWiki substantially easier to install
by third-parties
Library-ization of MediaWiki
- MediaWiki components
- CLDR parser
- cssmin
- HashRing
- Aaron's UUID generator
- Zip directory reader
- PHP JSON parser
- Monolog
- Profiler
- There is a lot of code that is reusable save for wfDebug /
WfProfile calls are often the only things
- Other components
- Pybal
Benefits:
- Encourages open-source contributions
- Encourages developers to think in terms of clearly-defined interfaces
Configuration management
- Allowing Stewards to set certain things in the UI (e.g. per-wiki logos)
- Cleaner command line methods to make configuration changes
- Get rid of configuration globals
- Requests for comment/Extension
registration<https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration>
- https://gerrit.wikimedia.org/r/#/c/109850/
Hey,
I can't make today's meeting, so I'm emailing in my status update.
SecurePoll update: I've arranged a meeting with Philippe and James on
Wednesday to catch up with them and see what needs improving.
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
https://bugzilla.wikimedia.org/show_bug.cgi?id=64622
Error generating thumbnail: As an anti-spam measure, you are limited
from performing this action too many times
Multimedia Team also knows about it (and I pinged them about it
yesterday), but there hasn't been any movement.
Anyone want to get the ball rolling for them? Please.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
I ran benchmarkParse.php on [[Barack Obama]] with a three different
hhvm builds: debug, release and release with ALWAYS_ASSERT. The
overhead of ALWAYS_ASSERT was smaller than the error bars, probably
less than 1%. The overhead of debug mode was a factor of 7 increase in
parse time.
I confirmed that the ALWAYS_ASSERT build did actually have assertions
enabled, by using objdump -t to check for symbols that are
conditionally compiled.
-- Tim Starling
https://bugzilla.wikimedia.org/show_bug.cgi?id=53770
Error:
You do not have permission to move this page, for the following
reason:
The target filename is invalid
There are some examples in the bug comments. Bawolff said this:
"Taking a brief look over the code. This error appears to be coming from
LocalFileMoveBatch::doDBUpdates in the case it can't update the db.
However in the case of that error, its supposed to rollback the db
transaction, and bail, all before touching any files on the file
system..."
Help?
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi everyone,
Tim and I did a first pass on prioritizing the backlog yesterday. Results
are here:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Backlog
It's useful to understand our definitions of priority for purposes of this
pass. "High priority" means "we need to explicitly consider this idea as
something we do next quarter", and it also puts additional onus on us to
make sure that it's well-defined and well-scoped. "Medium" means "we
should consider this idea as something we do next quarter, but we may not
get around to an explicit conversation". "Low" means "we're almost
certainly not going to give this serious consideration for next quarter".
If there's something you feel needs promotion to a higher priority, either
make the case on the talk page, or be bold and make the change. Early in
the planning cycle (i.e. now) I'd like to encourage you to be bold. As we
get closer to the end of the planning cycle (July 16 review), I'll request
a little more rigor before making changes.
Thanks
Rob