Perhaps the new installer could contain that as an option during the
inital setup.
Like a two or three-column thing with a bunch of checkboxes.
Language: English [\/]
Default theme (X) Vector (_) Monobook (_) Foobar
Common Extension: [X] ParserFunctions [X] SpecialInterwiki
[X] Cite.php [X] CharInsert
[X] CategoryTree
etc. you get the idea
Op 29 sep 2010, om 01:15 heeft Platonides het volgende geschreven:
Chad wrote:
On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal
wrote:
when to move features out of core and into an
extension or
out of an extension and into core.
I don't think anyone's commented on the former (everyone's been
talking about pushing in, not pulling out). IMO, the conditions for
splitting something into an extension
A) Not a lot of people use it anyway (hard to gauge)
B) It probably shouldn't have been in core in the first place (eg:
AskSQL)
So far, the only successful case I can think of offhand for splitting
an extension out was AskSQL, but it's a perfect example of what
should happen.
DumpHTML was also split from core. texvc should have been moved out of
core, but since that would change things set there from the
mwbeginning,
nobody did it yet.
1. This
is a very valid and important goal, but am unconvinced and
merging extensions into core is the only way to achieve it. We
can, for instance, take advantage the new installer that demon
is
working on which has the ability to automate the installation of
extensions at setup-time.
Quick note on the installer. It only enables extensions that already
reside in your extensions folder. Since we don't distribute any with
the default package, this might not be terribly useful. More awesome
is Jeroen's GSoC work on extension management. Something to look
at post-1.17 branch though.
I think the point is to start shipping mediawiki with common
extensions
there.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l