Talk:Requests for comment/Extension release management

MediaWiki is the ONLY repo

Specifically I'm addressing:

Extension pages can ONLY exist (excluding subpages) if an extension has been defined in the database, a path to the repo given, and author(s) defined [problem 3]

I've seen this sentiment in a few places, and I have to say it's a bit presumptuous. I don't think MediaWiki should worry too much about other people's repos, but to purposefully go out of their way to make it hard for them is pretty harsh. If you want to be a central place to document things mediawiki, then be a bit more open the fact people will put their code elsewhere (git, cvs, their server, their store). You're not the "only appstore". Specifically we have 3rd parties packaging MediaWiki as their backend (see SMW Plus) and building on top of it, and sometimes their stuff is backwards compatible back to us (see Halo). That doesn't mean they'll want to maintain things in multiple places, but mediawiki people gain by knowing they exist out there (see SMW).

There are also some real reason why people might steer clear of the the MW repo; it's a copyright nightmare because no permissions on extensions are being enforced. Anyone can go in and change anyone else's code (and they do) even though they have no legal basis to do so. And does MediaWiki really want to drive away commercial efforts as well? What about for-pay extensions and skins? If you are serious about becoming a higher-tier wiki application (see Confluence, others) then you have to take these things into account. I think the repo is a great idea, but don't force people into it. Myself, I've put a EULA into each extension file (see Extension:Realnames) that assign copyright back to me for any contributions, so I'm not too worried. I still reserve the right to re-license my work and someone's change doesn't hamper my ability to sell my extensions under a pay-what-you-want store.

--Quadir 18:32, 20 September 2011 (UTC)

I am sorry if I gave the impression that only the Wikimedia repo (be it SVN or Git) would be where we host extensions. I am very much in favor of allowing people to use their own repos, and in fact I consider that to be a part of the initial configuration for a "new extension." I do, however, believe that MediaWiki.org is the only place that MediaWiki should "dial home" to for information about releases. It is the canonical source, and I really hate to fracture documentation elsewhere. So like I outline, you'd be able to define your project, repo url, maintainers, and then say "this branch or this tag as of this revision constitutes a release." Per our discussion last night, you like the idea of considering each revision a release, so maybe we can add that option too on an extension-by-extension basis.

With regard to licensing, I'm sorry you feel that way. By allowing people to use their own repos (like I outlined above), this would pretty much alleviate the issue entirely. Most of the extensions in our SVN repo are GPL (or some other strong copyleft license), and we welcome contributors to add. If you have some sort EULA you want developers to abide by...that's fine in your repo. Your repo--your rules. :)

Hope this clears some things up. ^demon 19:17, 20 September 2011 (UTC)

Extension:Update

Although I started before being aware of this page and other efforts, I'd like to point out that I've begun work on Extension:Update which shares many of the same goals. Since biting off more than you can chew is a real danger in such a large project (and a pitfall apparently other projects have encountered), I've decided to use an iterative approach of providing working, value-added functionality in small increments with as little involvement from MediaWiki/WMP as possible. My first version (to be released tonight) includes an enhanced Special:Version which indicates updates to MW through Template:MW_stable_release_number, PHP through Template:MW_stable_php_requirement, MySQL through Template:MW_stable_mysql_requirement and extensions through their individual Extension: page infobox version= setting. I use action=raw per recommendation in the API docs to grab the text instead of trying to introduce new API functions. My next release will focus on adding subversion support. I also have a bug filed to add meta data to extensions downloaded through Extension:ExtensionDistributor. Comments and ideas welcome at Extension Talk:Update and Extension Talk:Update/Roadmap --Quadir 18:45, 20 September 2011 (UTC)

Extension data should be stored in a relational manner (so we can track dependencies, etc). New API methods *should* be introduced for providing this data. Screen-scraping is inherently evil and prone to failure. ^demon 19:10, 20 September 2011 (UTC)

Agreed, and an API would mean any MW derived product or wiki could also serve as a "base" home for an extension. Screen scrapping and templates unfortunately currently tie my extension versioning to MW. It's not a big deal for the MW core stuff, although again some kind of API would let derived products get easy support. And once you start running a non-stable branch it all falls appart currently. So I'm definitely interested in seeing that come to fruition. For my first release I'm just trying to get something usable and "better than nothing" out there. --Quadir 19:32, 20 September 2011 (UTC)

Avoid the pitfalls of WordPress plugin management

If you implement a GUI for managing extensions, like WordPress does, be aware that their approach has pitfalls that make it unsuitable for large-scale use. If you manage (say) 10+ wikis, you definitely do not want to fiddle with a GUI ten times: this is time-consuming and will cause errors (e.g., when you forget to enable the Foo extension on one of the ten wikis). I posted about this in mediawiki-l awhile back. The requirements that would be important to an extension manager are:

• Make sure the configuration is easily deployed to multiple targets as part of a formal release process: e.g., rsync to your 10+ wikis. With WordPress, I pull my hair out every time an admin makes a change through the GUI on one site and doesn't document it. It can be hard to identify that change so it can be documented, version-controlled, and deployed to other sites.
• Make sure "Undo" is easy, no matter how long ago you made the change. When I change settings in the WordPress GUI and click "OK" or "Save", I sometimes have to work hard to roll back those changes or even remember what they were.
• Make sure all changes made through the GUI can easily be tracked, rolled back, diffed, etc., using any off-the-shelf version control system. If your GUI generates a config file to be version controlled, be careful that its final form exactly reflects the change you made, and only that change: (Your "save" function should not reorder lines, reformat the text, add unwanted commands that set default values, etc. This screws up diffs.)
• Provide some kind of purely text-based API that can be run from a command line (over SSH, etc.) for secure remote administration. With text, you also can use your favorite editor (emacs, vi, etc.) instead of whatever the GUI designer gives you, which means you can work faster with fewer errors using familiar tools.

--Maiden taiwan (talk) 17:07, 30 July 2012 (UTC)

I agree. There is one question, though, where Wordpress can serve as a role model: when it comes to crowdsourcing compatibility information. Look at jetpack for example. Under "Compatibility" it collects data for a given WP and a given plugin version. If there are enough users saying a certain combination works for them, it's likely that it works for you as well. If we manage to get extension developers for MW to tag their commits for certain releases, and gather user information in a similar was, this could be immensely helpful. --Mglaser (talk) 21:31, 14 October 2013 (UTC)

Dependencies within extensions

I think it would be great if the dependencies within extensions could also be addressed. For example, extension Maps depends on Validator which in turn depends on DataValues; SemanticMaps depend on Maps and SemanticMediaWiki --Nischayn22 (talk) 19:05, 26 June 2013 (UTC)