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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
