Last modified: 2014-10-09 19:02:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38802, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36802 - ExtensionDistributor: Implement support for having both Git extensions and SVN extensions (both with appropiate branch list and trunk/master)
ExtensionDistributor: Implement support for having both Git extensions and SV...
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
wmf-deployment
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 34375 35574 37946 38012
Blocks: 37569 38188
  Show dependency treegraph
 
Reported: 2012-05-12 23:57 UTC by Krinkle
Modified: 2014-10-09 19:02 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2012-05-12 23:57:44 UTC
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

2) 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
Comment 1 Aaron Schulz 2012-05-13 00:31:59 UTC
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.
Comment 2 Amgine 2012-05-13 04:10:44 UTC
(In reply to comment #0)
> 2) 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.
Comment 3 Mark A. Hershberger 2012-05-14 17:39:17 UTC
(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?
Comment 4 Sam Reed (reedy) 2012-05-18 00:16:44 UTC
(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.
Comment 5 Antoine "hashar" Musso (WMF) 2012-05-18 06:45:18 UTC
(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
Comment 6 Krinkle 2012-06-25 00:11:13 UTC
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.)
Comment 7 Chad H. 2013-01-08 20:41:12 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links