Last modified: 2014-11-17 10:34:52 UTC
Vector has outlived its usefulness as an experiment. The good parts should be merged into core MediaWiki; either into the Vector skin, or as core features. This bug is about determining which are the good parts and what to do with the rest. [I'm creating this bug per consensus on wikitech, on a thread starting with http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066170.html]
So basically, apart from the PHP experimenting-related cruft, Vector extension has six JS/CSS modules which we need to take care of. * collapsiblenav * Considered stable, enabled on WMF wikis by default, currently configurable in preferences. I don't like it personally and I have it disabled in my prefs; it should probably be merged, but I'd like to keep the possibility of disabling it in prefs. * collapsibletabs * Considered stable, enabled on WMF wikis and not configurable. This is really a workaround to the issue that Vector's layout breaks down on smaller screen resolutions (bug 44386), but a useful and reasonably neat one, so it should be kept. * editwarning * Considered stable, *disabled* on WMF wikis by default, can be enabled in preferences. Personally I think it's cruft and useless, and the code is awfully convoluted to make it sort of work; people seem to use it, though. * expandablesearch * I have no idea what this is, but it's probably disabled entirely and unknown of for a reason. Let's forget about it. * footercleanup * Enabled only on en.wiki, non-configurable. Very nice and should be integrated into core CSS (that is, for all skins, not just Vector); will need some care first to ensure it doesn't break the edit interface on other wikis. (You wouldn't believe the things people insert there.) * sectioneditlinks * Experiment, disabled everywhere; bug 41729 deals with it. To sum up: * collapsiblenav and collapsibletabs: merge into the Vector skin * editwarning: I have no idea * expandablesearch: kill and forget * footercleanup: ensure it works properly, then merge into core CSS (all skins) * sectioneditlinks: reimplement in core (see bug 41729), then kill and forget
(Stupid bugzilla wrapping at 78 chars when I hard-wrapped at 80.) (In reply to comment #1) > * editwarning > * Considered stable, *disabled* on WMF wikis by default, can be enabled in > preferences. Personally I think it's cruft and useless, and the code is > awfully convoluted to make it sort of work; people seem to use it, > though. Actually it's enabled by default on WMF wikis, but disabled by default in the extension. Sorry.
(In reply to comment #1) > * expandablesearch > * I have no idea what this is, but it's probably disabled entirely and > unknown of for a reason. Let's forget about it. By its name, it looks like this could be code to automatically expand the search box when clicked or when the search sting exceeds a certain length. Just guessing, though.
(In reply to comment #3) > (In reply to comment #1) > > * expandablesearch > > * I have no idea what this is, but it's probably disabled entirely and > > unknown of for a reason. Let's forget about it. > By its name, it looks like this could be code to automatically expand the > search box when clicked or when the search sting exceeds a certain length. > Just > guessing, though. When focused. It's important for search usability for the search input to be large enough to accommodate practically anything the user would input into there.
*** Bug 43689 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 43689 has been marked as a duplicate of this bug. *** This seems to make matters messier. Large bugs like this are notoriously more difficult to get resolved than smaller, discrete bugs.
I agree. Bug 43689 should (and does) block this (it's part of the overall task), but it's not a duplicate. I'm also marking this a tracking bug.
Could this be a Google Summer of Code project? If you think this makes sense and the maintainers would be willing to integrate the changes if they meet the quality criteria, then we would need urgently * A short description of the tasks to be done and the skills required. I can help on this. * A mentor or two. I cannot help on this. The proposal should be listed at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Skins See also the GSOC 2013 project ideas that have been accepted so far: https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas
(In reply to comment #8) > Could this be a Google Summer of Code project? Not really; right now, with most of the work on footercleanup and sectioneditlinks done (just not merged yet), this is rather work for a few busy evenings rather than a summer. I was wondering whether to propose solving as much of bug 44881 (wider one, about Vector skin & extension issues in general) as possible for a GSOC project, but I'm not sure if it would make sense - the bugs there cover an extremely wide spectrum and often are non-actionable or would require some careful design work. There is probably a summer's worth of stuff to do there, though.
There are six sub-bugs for the separate components now, to make it easier to see what's the progress on this and who's working on what: * footercleanup: bug 43689 * sectioneditlinks: bug 41729 * collapsiblenav: bug 46512 * collapsibletabs: bug 46513 * editwarning: bug 46514 * expandablesearch: bug 46515
(In reply to comment #9) > (In reply to comment #8) > > Could this be a Google Summer of Code project? > > Not really Understood. Let's move the discussion for possible alternatives at http://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#Phase_out_the_Vector_extension.3B_merge_the_good_parts_into_core_25495 I have gone through issues tracked at bug 44881 and I have left my feedback in that thread.
Sorry I resolved the wrong bug.
As the Target Milestone on this ticket has been set to 1.22.0: According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072030.html "MediaWiki 1.22 is slated for release on November 30th, at the very latest." If this is still intended to get fixed for 1.22.0, a patch is needed soon.
The only dependency left is bug 46512, which has Jon's patch pending review. Getting this done in time for 1.22 looks realistic to me. Release manager's help will be needed to update the tarballs and the documentation – the Vector extension should no longer be bundled after this is finished, and the reason (it's been merged into core) will have to be documented so that people don't freak out. Upgrade guides should mention that the extension should be uninstalled before installing MW 1.22 (but just updating it will do fine as well).
Hooray! Solving the blockers only took eight months, eh. I was just about to rejoice, but first I dug in and noticed: * That a pesky thing called 'vector-noexperiments' preference exists (bug 54852), which needs to die before Vector can be safely undeployed from Wikimedia wikis – it does not block unbundling Vector from the tarball, though. * That the default true value for 'vector-simplesearch' preference is only set in Vector, not in core – I submitted Id5e96f5e to remedy that (not worth a separate bug IMO). This one does block unbundling.
Change 87028 had a related patch set uploaded by Bartosz Dziewoński: Remove dead code https://gerrit.wikimedia.org/r/87028
Change 87029 had a related patch set uploaded by Bartosz Dziewoński: Remove everything except for short information in README and Vector.php https://gerrit.wikimedia.org/r/87029
Current status is: four patches pending review – one on bug 54852, one in comment 15, two in comments above. The extension can be unbundled from 1.22 tarball assuming that patch from comment 15 is merged before release. The extension can be undeployed from Wikimedia wikis now, as far as I can see it. Needs ops involvement.
Change 87028 merged by jenkins-bot: Remove dead code https://gerrit.wikimedia.org/r/87028
Change 87029 merged by jenkins-bot: Remove everything except for short information in README and Vector.php https://gerrit.wikimedia.org/r/87029
(In reply to comment #18) > The extension can be undeployed from Wikimedia wikis now, as far as I can see > it. Needs ops involvement. Please spilt that out to a separate bug.
Everything mentioned has been merged, yay. Instead of filing a bug, I submitted a patch to clean up WMF settings: https://gerrit.wikimedia.org/r/87731 (but that is orthogonal to this bug anyway).
Upgrade notes (please expand and copyedit): https://www.mediawiki.org/wiki/MediaWiki_1.22#Vector_extension_merged
(In reply to comment #22) > Instead of filing a bug, I submitted a patch to clean up WMF settings: > https://gerrit.wikimedia.org/r/87731 Merged as well.
(In reply to comment #24) > (In reply to comment #22) > > Instead of filing a bug, I submitted a patch to clean up WMF settings: > > https://gerrit.wikimedia.org/r/87731 > > Merged as well. Does that mean this can be marked as fixed?
Not until Mark promises that he will handle the tarball stuff :) and we update the documentation on mw.org (it would be nice to do it at the same time we release 1.22). All of the coding is done and merged.
(In reply to comment #26) > Not until Mark promises that he will handle the tarball stuff :) and we > update the documentation on mw.org (it would be nice to do it at the same time > we release 1.22). All of the coding is done and merged. So, other than what is in Comment #14, what is needed?
As far as I know that's all – unbundle it and document that we did it.
Change 89413 had a related patch set uploaded by MarkAHershberger: Update make-release.py. https://gerrit.wikimedia.org/r/89413
Not merged yet.
Change 90144 had a related patch set uploaded by MarkAHershberger: Removed Vector from 1.22. https://gerrit.wikimedia.org/r/90144
Change 90144 merged by jenkins-bot: Removed Vector from 1.22. https://gerrit.wikimedia.org/r/90144
Hooray, less technical debt! Thanks to everyone who helped resolve this bug.
