On 05/13/2015 04:11 PM, Matthew Flaschen wrote:
Thanks for sending out this summary Matt.
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".
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":"..."}
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.
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:
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?
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.
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).
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!
3. 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