There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Of course they should be maintained! But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
On Mon, Oct 27, 2014 at 8:53 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Of course they should be maintained! But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
Sometimes code, MediaWiki extensions that are no longer maintained included, and haven't been for years, should just rot and die. Unusable/unused code shouldn't be localised. No one should spend valuable time getting code they don't want to use out of Subversion and into git/Gerrit. If someone REALLY has a use case for something that's still in Subversion, they'll make themselves known.
If you want to maintain a particular extension that is in Wikimedia's read-only Subversion, please request it to be moved to Gerrit, do the work on it to bring it up to par with the current code of code, and update the extension documentation page on MediaWiki.org. Please don't just dump code from one place where it's not maintained into another place where it's not maintained. Extension maintenance is not trivial, so you shouldn't assume that "someone" will just volunteer to start maintaining tens or hundreds of extensions no one worked on for years.
Siebrand
Il 27/10/2014 17:03, Siebrand Mazeland ha scritto:
On Mon, Oct 27, 2014 at 8:53 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Of course they should be maintained! But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
Sometimes code, MediaWiki extensions that are no longer maintained included, and haven't been for years, should just rot and die. Unusable/unused code shouldn't be localised. No one should spend valuable time getting code they don't want to use out of Subversion and into git/Gerrit. If someone REALLY has a use case for something that's still in Subversion, they'll make themselves known.
If you want to maintain a particular extension that is in Wikimedia's read-only Subversion, please request it to be moved to Gerrit, do the work on it to bring it up to par with the current code of code, and update the extension documentation page on MediaWiki.org. Please don't just dump code from one place where it's not maintained into another place where it's not maintained. Extension maintenance is not trivial, so you shouldn't assume that "someone" will just volunteer to start maintaining tens or hundreds of extensions no one worked on for years.
Siebrand _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think I was misunderstood. Most of them are just rubbish with no use cases, but I bet a few still have one. Unfortunately, if a user is running outdated code and can't just afford to update it, they would stick with an outdated MediaWiki. This can block further uses of the software outside of the WMF. I keep seeing lots of similar cases in the Support desk https://www.mediawiki.org/wiki/Project:Support_desk.
If a project appears to be abandoned but is in Gerrit already, what is the process to become the maintainer?
On Mon, Oct 27, 2014 at 11:38 AM, Ricordisamoa <ricordisamoa@openmailbox.org
wrote:
Il 27/10/2014 17:03, Siebrand Mazeland ha scritto:
On Mon, Oct 27, 2014 at 8:53 AM, Ricordisamoa <
ricordisamoa@openmailbox.org> wrote:
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN
https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Of course they should be maintained!
But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
Sometimes code, MediaWiki extensions that are no longer maintained
included, and haven't been for years, should just rot and die. Unusable/unused code shouldn't be localised. No one should spend valuable time getting code they don't want to use out of Subversion and into git/Gerrit. If someone REALLY has a use case for something that's still in Subversion, they'll make themselves known.
If you want to maintain a particular extension that is in Wikimedia's read-only Subversion, please request it to be moved to Gerrit, do the work on it to bring it up to par with the current code of code, and update the extension documentation page on MediaWiki.org. Please don't just dump code from one place where it's not maintained into another place where it's not maintained. Extension maintenance is not trivial, so you shouldn't assume that "someone" will just volunteer to start maintaining tens or hundreds of extensions no one worked on for years.
Siebrand _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think I was misunderstood. Most of them are just rubbish with no use cases, but I bet a few still have one. Unfortunately, if a user is running outdated code and can't just afford to update it, they would stick with an outdated MediaWiki. This can block further uses of the software outside of the WMF. I keep seeing lots of similar cases in the Support desk https://www.mediawiki.org/ wiki/Project:Support_desk.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If the old maintainer is still around, ask them if they are ok with you taking over. ( just to avoid stepping on toes)
If they cant be reached, ask at http://www.mediawiki.org/wiki/Gerrit/Project_ownership explaining why you want to take over maintinance of the extension. Helps if you have pre existing commits to said extension you can point to (or even pending commits), but generally the barrier should be pretty low for non-wmf deployed extensions that are clearly abandoned. (Imo).
--bawolff
On Oct 27, 2014 1:58 PM, "James Montalvo" jamesmontalvo3@gmail.com wrote:
If a project appears to be abandoned but is in Gerrit already, what is the process to become the maintainer?
On Mon, Oct 27, 2014 at 11:38 AM, Ricordisamoa <
ricordisamoa@openmailbox.org
wrote:
Il 27/10/2014 17:03, Siebrand Mazeland ha scritto:
On Mon, Oct 27, 2014 at 8:53 AM, Ricordisamoa <
ricordisamoa@openmailbox.org> wrote:
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote:
There are currently several hundreds extensions hosted on SVN
https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to
merge
extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of
mass-moving?
andre
Of course they should be maintained!
But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
Sometimes code, MediaWiki extensions that are no longer maintained
included, and haven't been for years, should just rot and die. Unusable/unused code shouldn't be localised. No one should spend
valuable
time getting code they don't want to use out of Subversion and into git/Gerrit. If someone REALLY has a use case for something that's
still in
Subversion, they'll make themselves known.
If you want to maintain a particular extension that is in Wikimedia's read-only Subversion, please request it to be moved to Gerrit, do the
work
on it to bring it up to par with the current code of code, and update
the
extension documentation page on MediaWiki.org. Please don't just dump
code
from one place where it's not maintained into another place where it's
not
maintained. Extension maintenance is not trivial, so you shouldn't
assume
that "someone" will just volunteer to start maintaining tens or
hundreds
of extensions no one worked on for years.
Siebrand _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think I was misunderstood. Most of them are just rubbish with no use cases, but I bet a few still have one. Unfortunately, if a user is running outdated code and can't just afford
to
update it, they would stick with an outdated MediaWiki. This can block further uses of the software outside of the WMF. I keep seeing lots of similar cases in the Support desk https://www.mediawiki.org/ wiki/Project:Support_desk.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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. 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. The talk page might provide useful info if people are reporting they cannot get it to work, but that's as far as you'll get without installing it and testing it yourself.
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
-- Ryan Schmidt Sent from my iPhone
On Oct 27, 2014, at 10:53 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 27/10/2014 16:38, Andre Klapper ha scritto:
On Mon, 2014-10-27 at 16:08 +0100, Ricordisamoa wrote: There are currently several hundreds extensions hosted on SVN https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ and many of them are still working according to www.mediawiki.org. However, a quick glance shows that many of them are overlapping each other and likely to be unmaintained. It should be of interest to the MediaWiki Cooperation https://www.mediawiki.org/wiki/MediaWiki_Cooperation group to merge extensions where appropriate and move them to git if still useful.
If nobody volunteers to maintain them, what's the gain of mass-moving?
andre
Of course they should be maintained! But if they're moved to Git, their i18n can be hosted on TranslateWiki and benefit from regular updates.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Adding to what Skizzerz and Siebrand said: there are "only" 306 extensions in SVN of which we didn't know the status (including usefulness) and back then I contacted all their authors: https://www.mediawiki.org/wiki/Git/Conversion/Extensions_still_in_svn#Unsorted_items If you see so many cases of extensions which should be migrated because people want to use them but are having problems, you could make a new list. http://wikiapiary.com can also help you select further SVN extensions of relevance. It's also useful if you tell users to file bugs for each extension they really need to get migrated. When we have more information on the problem, we can see if a change in process is needed (e.g. a proactive search for maintainers for some extensions).
Nemo
P.s./premise 1: unlike Siebrand, I think most users will *not* get themselves heard. That's why with WikiTeam I've been spidering the web for years, to acquire all the information possible. It only took me 300 $ to get the last list of wikis: https://wikiapiary.com/wiki/Category:Oct_2014_Import. Now go use the data! P.s./premise 2: it's a bit disturbing to hear "volunteers X _should_ be interested in Y". The MediaWiki Cooperation is open for new members and none of the above requires superpowers nor a bolla papale; if you think an activity should be done under that group, join the group and to the activity.
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.
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.
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.
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.
[1] https://www.mediawiki.org/w/index.php?title=Git/New_repositories/Requests/En... [2] https://www.mediawiki.org/w/index.php?title=Extension:WhosOnline&diff=pr... [3] https://www.mediawiki.org/wiki/Extension:WhosOnline [4] https://www.mediawiki.org/w/index.php?title=Git/New_repositories/Requests/En... [5] https://www.mediawiki.org/wiki/User:Jimbojw [6] http://jimbojw.com/wiki/index.php?title=Blog [7] https://www.mediawiki.org/wiki/Gerrit/Project_ownership
Thanks and regards, -- Jack Phoenix MediaWiki developer
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
On Thu, Oct 30, 2014 at 8:24 PM, Chad innocentkiller@gmail.com wrote:
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.
If someone wants to start discussing the details...
Define a process to import and create repositories https://phabricator.wikimedia.org/T1009
Hi Jack,
On Thu, Oct 30, 2014 at 08:53:29PM +0200, Jack Phoenix wrote:
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 [...].
I am all for making the SVN imports simpler and quicker.
And I am fine with assuming that SVN repos are unmaintained, and shortcutting the process if a new maintainer steps up.
However, I am with Chad, and would not want to bring SVN repos to gerrit, if no new maintainer is in sight.
Have fun, Christian
wikitech-l@lists.wikimedia.org