On Thu, Oct 30, 2014 at 11:53 AM, Jack Phoenix jack@countervandalism.net wrote:
There's a lot I'd have to say on the subject, but I think the one thing we all can agree is this: it should be easy for people to share their code with others via Wikimedia's git service(s). We want third parties to share and go open, not close down their repositories and pretend that sharing their code isn't worth the effort.
Yes.
On Mon, Oct 27, 2014 at 6:08 PM, Ryan Schmidt skizzerz@gmail.com wrote:
i18n is the least of our concerns with respect to unmaintained
extensions.
If they don't even work with recent MediaWiki versions in the first
place,
getting them translated to 200 languages is not only pointless, but actually harmful as it diverts translators' time and attention away from projects that actually work/are maintained.
+2.
Note that what the extension page says on mw.org is not an accurate indicator for whether or not an abandoned extension works, because in all likelihood the page hasn't been updated in years.
Yeah, I've noticed this same phenomenon in "my" extensions where I try to keep at least somewhat meaningful version numbers and update them as (breaking) changes are made, but sometimes commits "slip" into the repository without anyone bothering to update the MW.org page, which I find problematic (but admittedly it's a separate issue). "If it's on git.wikimedia.org it has a MW.org page" is generally speaking a good rule of thumb and I can't recall many extensions or skins that would contradict this statement, so I wish people would edit the documentation when making changes.
If someone is interested in maintaining an extension currently in SVN, I think the current method of requesting a new Git repository[1] on a case-by-case basis works just fine (at least, I'm unaware of any issues with it).
[1] https://www.mediawiki.org/wiki/Git/New_repositories/Requests
The main problem is a fundamental one here if you ask me: the very concept of "requesting" it. During the SVN era you could just create a folder whenever you wanted to publish a new extension instead of having to wait for many days for the repository to be created. It's obvious that we can't let everyone and their cat create new git repositories, but the permission to create new repos could and should be a restricted, yet somewhat more widely available one, like the "editbugs" permission on Bugzilla. Not available to all users by default, but available to a group of trusted users -- a group bigger than the mediawiki-core gerrit group, if you ask me.
I agree, having to request is problematic. The main reason this happened is that Gerrit has always made it easier to screw up than do it right when creating your project (it's not just that you *can* screw up, but that the defaults *encourage* a non-admin to screw up).
If it was the mediawiki-core group, that might scale. It's a far smaller group. The whole thing is rather silly I'm afraid as I've never scaled this process out beyond Christian and myself really.
I think this should be a much *much* larger group in Phabricator than we've done in Gerrit. It's much harder to screw yourself over.
For importing extensions from SVN, the request workflow somewhat makes sense, although I do want to believe that it could be more automated, too (but this point's moot anyway now that we're once again shuffling the entire technical workflow with Bugzilla -> Phabricator and -- hopefully -- gerrit -> Phabricator transition).
But that the process works just fine? I beg to disagree. Getting an unmaintained [2] yet somewhat popular extension, WhosOnline [3], moved from SVN to git was a somewhat bumpy process. Even though QChris mixed up things a bit, apologized nicely and explained his actions [4], I can't but to wonder about the current process. First off, if it's hosted on Wikimedia's servers -- on-wiki fair use images etc. excluded -- it oughta be properly licensed under a free content license. As far as I'm aware, this has been relatively consistently enforced for extensions and the like. Ergo, if someone wants to fork an extension, they have no legal limitations on that and they can do it whenever they wish to.
On the other hand, we have the maintainership/extension author's/creator's veto. Obviously the extension's original author or authors own the copyrights to the code; that's a given which nobody is questioning here. But I think it's safe to assume that the extensions currently hosted on Wikimedia's SVN are unmaintained and as such, anyone willing to step up and maintain them is a definite improvement over the status quo. To illustrate with a real-life example: Jim R. Wilson [5] was a prominent MediaWiki developer several years ago, who wrote 16 extensions (published on MW.org), some of which are still popular. However, his last edit on MediaWiki.org was over two years ago, and the last blog post on his blog [6] related to the release of a MediaWiki extension is dated 2009. In light of this, it's sufficient to say that Jim isn't maintaining the extensions he wrote, at least not now. So if someone else is willing to do that, I'd guess many MediaWiki users and likely Jim himself would appreciate that.
I agree. If it's properly licensed and someone wants to take up maintainership there's no reason we shouldn't let them.
Therefore I propose the following: SVN repositories are to be imported on request without any additional bureaucracy involved, just like before. If and when someone wants +2 rights to a repository originally imported from Wikimedia's SVN, they'll submit a project ownership request [7]. Given that no WMF-deployed extensions -- obviously -- reside in SVN, I'd say that this is overall pretty trivial and will benefit both end-users wanting to use extensions which currently aren't actively maintained as well as developers wanting to develop these extensions. Furthermore it allows at least people in the mediawiki-core gerrit group to merge changes; this theoretically ensures that changes aren't lost in review limbo forever.
Sure, I don't have any problem importing SVN repos that someone wants to pick up maintaining again. What I *do* have a problem with is importing stuff that nobody cares about, just because it can be migrated. For all the i18n/maintenance reasons mentioned elsewhere in the thread.
(I'd also suggest if it's not super important to do yet to maybe hold off a bit until we're closer to Phabricator for code. Things in SVN are good candidates because they won't have any outstanding changes in limbo to worry about)
-Chad