In the next RFC meeting, we will discuss the following RFC:
* Improving extension management https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management
The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time:
* UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CEST: Wednesday 23:00 * Australia AEST: Thursday 07:00
-- Tim Starling
On 05/13/2015 02:48 AM, Tim Starling wrote:
In the next RFC meeting, we will discuss the following RFC:
- Improving extension management
https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management
The focus of the meeting was two aspects:
1. A way for the extension to specify which version(s) of MediaWiki core it worked with.
This was the focus of the majority of meeting. Basically, this would let an extension specify that a given commit (and thus, a given branch) worked with particular versions of core, using syntax like:
"supports": ">1.23<1.26"
Any syntax that Composer supports will work on the right.
There was a lot of support with this, with some desire for better communication, socialization, and documentation, and some debate over the key name. However, this was not unanimous. Outcome of this was "just submit a patch for it and we can continue the discussion in gerrit".
2. Tardist. Details at https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist . There wasn't much discussion of this, but some support based on having read it.
There was also some big-picture debate on whether we should be implementing a packaging/dependency system and various concerns:
1. Can we use Composer unmodified, whereas the current proposal/already implemented decisions is to use Composer for libraries, and build our extension system on top of it?
General reason we haven't done this is that extensions are not libraries, and have MediaWiki-specific concerns (e.g update.php). However, there was some push-back in today's meeting about whether this distinction is valid.
2. Should we instead use (or auto-generate) something like Debian packages, even if we don't actually try to get it into Debian proper. This means having our own Debian repo. People pointed out that to even start getting serious about this we have to at least package latest MediaWiki and provide it in a public repo. We haven't done this so far, and the latest MW in even Debian unstable is 1.19.20+dfsg-2.3 (latest release is 1.24, 1.25 coming out Real Soon Now).
Also, if Debian packages are our solution for manging extensions and core, what about people on Red Hat, Windows, BSD, etc.?
3. In general, has enough research been done on the existing packaging and dependency ecosystem to see if we can leverage an existing system?
Matt Flaschen
On 05/13/2015 04:11 PM, Matthew Flaschen wrote:
Thanks for sending out this summary Matt.
- A way for the extension to specify which version(s) of MediaWiki core
it worked with.
This was the focus of the majority of meeting. Basically, this would let an extension specify that a given commit (and thus, a given branch) worked with particular versions of core, using syntax like:
"supports": ">1.23<1.26"
Any syntax that Composer supports will work on the right.
There was a lot of support with this, with some desire for better communication, socialization, and documentation, and some debate over the key name. However, this was not unanimous. Outcome of this was "just submit a patch for it and we can continue the discussion in gerrit".
Mostly working patch is https://gerrit.wikimedia.org/r/#/c/210856/. I've implemented it using "supports" for now, but I'm open to other names. Some that were suggested in meeting were: * 'supports' (my initial idea) * 'supports-core' * "depends": {"mediawiki-core":"..."}
- Tardist. Details at
https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist . There wasn't much discussion of this, but some support based on having read it.
It would be nice if we could have another meeting to discuss this. Or maybe it should be on hold until we figure out part 1 first?
There was also some big-picture debate on whether we should be implementing a packaging/dependency system and various concerns:
- Can we use Composer unmodified, whereas the current proposal/already
implemented decisions is to use Composer for libraries, and build our extension system on top of it?
We've already decided to use composer for library management, and it really doesn't make sense to revisit that decision. If people want to, it should be a separate matter.
In my RfC I discussed and explained why extension are not libraries, and why using composer directly didn't make sense. I'm not sure if people didn't read that section or what.
- Should we instead use (or auto-generate) something like Debian
packages, even if we don't actually try to get it into Debian proper. This means having our own Debian repo. People pointed out that to even start getting serious about this we have to at least package latest MediaWiki and provide it in a public repo. We haven't done this so far, and the latest MW in even Debian unstable is 1.19.20+dfsg-2.3 (latest release is 1.24, 1.25 coming out Real Soon Now).
I'm excited that other people are interested in working on this, but it seems a bit weird to block implementing "wfUseMW" in extension.json over some magical Debian extension system. If people want to create and implement that, please, write your own RfC!
- In general, has enough research been done on the existing packaging
and dependency ecosystem to see if we can leverage an existing system?
This was probably the most frustrating part of the entire meeting. If people want to research debs/rpm/docker/etc. that's great, but we already had consensus in the last meeting to build our own system on top of composer classes, so I felt like we wasted a lot of time just re-hashing that.
-- Legoktm
On 14/05/15 09:11, Matthew Flaschen wrote:
Outcome of this was "just submit a patch for it and we can continue the discussion in gerrit".
Note that the patch has been in Gerrit for almost 24 hours with no negative comments on the principle, despite me adding almost everyone from the meeting as a reviewer.
https://gerrit.wikimedia.org/r/#/c/210856/
If there are still no negative comments after the [WIP] tag is removed, I will take that as evidence that the objections raised in the meeting have been withdrawn and I will approve the patch.
-- Tim Starling
Hi,
[Thread necromancy]
On 05/14/2015 10:27 PM, Tim Starling wrote:
On 14/05/15 09:11, Matthew Flaschen wrote:
Outcome of this was "just submit a patch for it and we can continue the discussion in gerrit".
Note that the patch has been in Gerrit for almost 24 hours with no negative comments on the principle, despite me adding almost everyone from the meeting as a reviewer.
https://gerrit.wikimedia.org/r/#/c/210856/
If there are still no negative comments after the [WIP] tag is removed, I will take that as evidence that the objections raised in the meeting have been withdrawn and I will approve the patch.
I removed the WIP tag on Sept. 1st, and no one has objected so far. I'd like to get this included in the 1.26 release (being branched on Tuesday) and hopefully have some time to update extensions and skins to use it as well.
Thanks, -- Legoktm
On Fri, Sep 18, 2015 at 6:30 PM Legoktm legoktm.wikipedia@gmail.com wrote:
I removed the WIP tag on Sept. 1st, and no one has objected so far. I'd like to get this included in the 1.26 release (being branched on Tuesday) and hopefully have some time to update extensions and skins to use it as well.
Tuesday? I thought it was next Tuesday, the 29th...
-Chad
On 18 September 2015 at 19:03, Chad innocentkiller@gmail.com wrote:
On Fri, Sep 18, 2015 at 6:30 PM Legoktm legoktm.wikipedia@gmail.com wrote:
I removed the WIP tag on Sept. 1st, and no one has objected so far. I'd like to get this included in the 1.26 release (being branched on Tuesday) and hopefully have some time to update extensions and skins to use it as well.
Tuesday? I thought it was next Tuesday, the 29th...
Well, https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap says we're cutting wmf24 as the last one, like with 1.25 (but I wrote it based on what I understood from Greg, so it might well be wrong and all my fault; for similar reasons, https://phabricator.wikimedia.org/tag/wmf-deploy-2015-09-29_(1.27.0-wmf.1)/ is dated a week next Tuesday).
J.
wikitech-l@lists.wikimedia.org