Page MenuHomePhabricator
Create Task
Maniphest T38802

ExtensionDistributor: Implement support for having both Git extensions and SVN extensions (both with appropiate branch list and trunk/master)
Closed, DeclinedPublic
Actions

Description

ExtensionDistributor seems to only look through svn branches, svn trunk and maybe (heard of it, but not seen in reality yet) git master.

However now that 1.19 is out and 1.20 in full development, site admins are having troubles finding a REL1_19 version of their favorite extensions.

We would need:

  1. Add support in ExtensionDistributor for downloading git branches (after selecting an extension, it would query (whether or not cached) a lit of available branches and after choice, package it up and send it
  1. A policy on branching because extensions are now in their own repositories, so core branches no longer branch extensions automatically
    • Whenever we branch core, run a script that branches all extensions as well. + Always complete
      • Extension author may know know about it and thus branching might occur at a wrong point. Of course this can be easily fixed, but still a burden.
    • We only branch core as we did for 1.19/1.20 and in addition, notify extension developers that they should branch their extension.
      • Not complete + But branches are chosen for and more stable

So overal the choice is, do we want to offer choices for each release no matter what (and risk it being a bad branch point), or let extension maintainers do it themselves, but thus many extensions won't have available branches for a certain MediaWiki version.

Whatever we do, we should do it soon because 1.19.0 is already released and ExtensionDistributor has no 1.19 package.

e.g.: https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Cite

Version: wmf-deployment
Severity: normal

Details

Reference
bz36802

Related Objects
Search...

Event Timeline

• bzimport raised the priority of this task from to High.Nov 22 2014, 12:21 AM
• bzimport added a project: WMF-General-or-Unknown.
• bzimport set Reference to bz36802.
• bzimport added a subscriber: Unknown Object (MLST).
Krinkle created this task.May 12 2012, 11:57 PM
aaron added a comment.May 13 2012, 12:31 AM

I'd prefer we branch all extensions with core. With git, they are bit less likely to be in bad states. And as long as authors can backport things as needed to keep branches stabler, then that seems OK.

I see a lot of people running into errors with mismatched core/extension version.

• bzimport added a comment.May 13 2012, 4:10 AM

wmf.amgine3691 wrote:

(In reply to comment #0)

  1. A policy on branching because extensions are now in their own repositories,

so core branches no longer branch extensions automatically

Is there a way to (automatedly?) test an extension is generically compatible with a given branch? if so, I would prefer WMF branch all *compatible* extensions with core.

MarkAHershberger added a comment.May 14 2012, 5:39 PM

(In reply to comment #2)

Is there a way to (automatedly?) test an extension is generically compatible
with a given branch? if so, I would prefer WMF branch all *compatible*
extensions with core.

I think we could do this with Jenkins. Jenkins could look for extension-specific tests and then run them. If non existed... hrm... Maybe default to "ok"?

Jenkins could then tag an extension "ok for 1.20". Ashar, what do you think?

Reedy added a comment.May 18 2012, 12:16 AM

(In reply to comment #0)

ExtensionDistributor seems to only look through svn branches, svn trunk and
maybe (heard of it, but not seen in reality yet) git master.

It just needs a copy of the git repo checking out, and then relevant configuration applying.

hashar added a comment.May 18 2012, 6:45 AM

(In reply to comment #3)

I think we could do this with Jenkins. Jenkins could look for
extension-specific tests and then run them. If non existed... hrm... Maybe
default to "ok"?

Jenkins could then tag an extension "ok for 1.20". Ashar, what do you think?

That seems unrealistic to me. Most extensions have no tests. I am sure that tests are not going to be enough to guarantee the extension is fine for a given version of MediaWiki.

Just let the extensions authors to tag their extensions. It is easier to scale out this way or I will handle being the bottleneck to fix zillions of broken tests ;-D

Krinkle added a comment.Jun 25 2012, 12:11 AM

1.19 for svn extensions is blocked by bug 34375.

1.19 for git extensions is either a simple config change, or it requires adding support for it in ExtensionDistributor (git-remote, parse git-branches etc.)

• demon added a comment.Jan 8 2013, 8:41 PM

ExtensionDistributor now supports git properly (see bug 37946), and will be deployed as part of 1.21wmf8.

On further thought, I've decided to drop support for SVN entirely. Extensions that are still in SVN are unmaintained, and we should not be encouraging our users to use unmaintained extensions. If they are indeed maintained, they should make their way into Git. Or if you really want to use an old extension, just grab it from SVN (like we used to do before ExtDist existed).

Marking this WONTFIX.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL