On Thu, Oct 30, 2014 at 11:53 AM, Jack Phoenix <jack(a)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(a)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