There has been some talk among developers and others about bundling some extensions with the tarball. The new installer supports enabling extensions during installation, so if we're going to do it, I would like to start bundling them with the 1.18 tarball.
Part of my motivation is that many people seem to install MediaWiki and expect a wiki that acts very similar to Wikipedia, with which they are more familiar. Now, part of the problem is documentation — these people don't understand how the functionality of MediaWiki is partitioned. But in addition to documentation, we can start providing the most expected functionality in the tarball.
Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before.
Assuming that we are going to put *some* extensions in, we need to decide which ones. Based on the problem reports in Bugzilla, I think at least Cite and ParserFunctions should be bundled. Others would be Gadgets and WikiEditor.
So my list would be:
Cite ParserFunctions Gadgets WikiEditor
Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include.
Mark.
On 8 June 2011 16:22, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Part of my motivation is that many people seem to install MediaWiki and expect a wiki that acts very similar to Wikipedia, with which they are more familiar. Now, part of the problem is documentation — these people don't understand how the functionality of MediaWiki is partitioned. But in addition to documentation, we can start providing the most expected functionality in the tarball.
Speaking as a tarball user: Yes please!
Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before.
Works for me.
So my list would be: Cite ParserFunctions Gadgets WikiEditor
I would also ask for CategoryTree, though my users (office workers, a mix of geeks and non-geeks) could live without it.
Suggestion: ask on mediawiki-l and mwusers.com, where tarball users might be found.
- d.
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before.
Since we're going down the road of offering different tarballs, can we also get an "ultra-lite" that only has MessagesEn?
-Chad
On 08.06.2011, 19:49 Chad wrote:
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before.
Since we're going down the road of offering different tarballs, can we also get an "ultra-lite" that only has MessagesEn?
English-only seems kinda OTT, however a release with world's top 20 languages will satisfy 99% users and will still be significantly smaller.
On Thu, Jun 9, 2011 at 2:02 PM, Max Semenik maxsem.wiki@gmail.com wrote:
English-only seems kinda OTT, however a release with world's top 20 languages will satisfy 99% users and will still be significantly smaller.
I also remember hearing lots of opposition about this last time it was brought up. If I remember correctly, the main argument was that the other language files are mostly for end-users, not for sysadmins who want to just save as much space as they can.
Well if I'm setting up an internal wiki for 10 people, saving space may be beneficial over supporting 250+ languages no one speaks.
-Chad On Jun 9, 2011 2:54 PM, "Casey Brown" lists@caseybrown.org wrote:
On Thu, Jun 9, 2011 at 2:02 PM, Max Semenik maxsem.wiki@gmail.com wrote:
English-only seems kinda OTT, however a release with world's top 20 languages will satisfy 99% users and will still be significantly smaller.
I also remember hearing lots of opposition about this last time it was brought up. If I remember correctly, the main argument was that the other language files are mostly for end-users, not for sysadmins who want to just save as much space as they can.
-- Casey Brown Cbrown1023
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jun 9, 2011 at 11:58 AM, Chad innocentkiller@gmail.com wrote:
Well if I'm setting up an internal wiki for 10 people, saving space may be beneficial over supporting 250+ languages no one speaks.
At the moment the *entire* languages/ dir in trunk comes to... 43 megabytes. (Not counting the complete copy of every file in the .svn subdir in a subversion checkout; people in this situation apparently are working from tarballs so that's not there.)
With English only.... 1.2 megabytes, for a saving of ~42 MB.
The simple expedient of gzipping the message files would reduce it to 13 megabytes, for a saving of ~30MB with *no* loss in functionality.
Of course, your users could fill up 30-40 megabytes' worth of text and images in just a few minutes, so even the savings of removing them all is pretty piddly...
If there is a compelling reason to reduce the size, switching to a gzip-friendly format would be simpler: almost as much savings as removing the files, but without losing anything.
-- brion
On 11-06-09 12:09 PM, Brion Vibber wrote:
On Thu, Jun 9, 2011 at 11:58 AM, Chad innocentkiller@gmail.com wrote:
Well if I'm setting up an internal wiki for 10 people, saving space may be beneficial over supporting 250+ languages no one speaks.
At the moment the *entire* languages/ dir in trunk comes to... 43 megabytes. (Not counting the complete copy of every file in the .svn subdir in a subversion checkout; people in this situation apparently are working from tarballs so that's not there.)
With English only.... 1.2 megabytes, for a saving of ~42 MB.
The simple expedient of gzipping the message files would reduce it to 13 megabytes, for a saving of ~30MB with *no* loss in functionality.
Of course, your users could fill up 30-40 megabytes' worth of text and images in just a few minutes, so even the savings of removing them all is pretty piddly...
If there is a compelling reason to reduce the size, switching to a gzip-friendly format would be simpler: almost as much savings as removing the files, but without losing anything.
-- brion
;) switching the format, whether we gzip or not would be a nice idea.
I believe I mentioned the advantage of using a format that would not be a php injection security vulnerability if we permitted to be updated on the fly. ie: Being able to instantly propagate batches of new translations from TranslateWiki to live sites. Perhaps allowing peer-reviewing of messages as a method of deciding how instantly to apply a message to live. Course as long as we make sure we don't have html injection vulns in our messages and we restrict changes of .js/.css messages.
Hey,
Assuming that we are going to put *some* extensions in, we need to decide
which ones.
As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs.
[0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
While Vector is the default skin, the Vector extension should probably be bundled too.
- Trevor
On Wed, Jun 8, 2011 at 9:00 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
Assuming that we are going to put *some* extensions in, we need to decide
which ones.
As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs.
[0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jeroen De Dauw wrote:
As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs.
[0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html
Are you familiar with ExtensionFunctions.php? This extension kind of reminds me of it. I only briefly read through the docs, but it seems like the kind of code that should be in core, particularly if multiple extensions are relying on it. MediaWiki administration is already cumbersome; added dependencies should be killed when possible, not encouraged.
MZMcBride
Mark A. Hershberger wrote:
Assuming that we are going to put *some* extensions in, we need to decide which ones. Based on the problem reports in Bugzilla, I think at least Cite and ParserFunctions should be bundled. Others would be Gadgets and WikiEditor.
So my list would be:
Cite ParserFunctions Gadgets WikiEditor
Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include.
Mark.
I'd also include: * Vector
Maybe worth consideration: * Renameuser * CategoryTree * DismissableSiteNotice[1] * ExpandTemplates
-- Krinkle
[1] Perhaps move this to core ? Probably super easy to do with modern javascript (if needed, could be disableable thru LocalSettings.php
On Wed, Jun 8, 2011 at 5:22 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
So my list would be:
Cite ParserFunctions Gadgets WikiEditor
ConfirmEdit (rationale: every single public wiki I've setup dies without this)
On 09/06/11 03:25, Łukasz Garczewski wrote:
ConfirmEdit (rationale: every single public wiki I've setup dies without this)
That's a pretty good example of an extension which is not supported by the installer at the moment. There's a python script which generates the images, and it takes so long that if you ran it from the web installer, you would risk a timeout.
There has been some talk on mediawiki-l suggesting that FancyCaptcha is broken anyway, and that some wikis using it have been spammed to death.
Maybe AbuseFilter would be a better anti-spam choice.
-- Tim Starling
On Thu, Jun 9, 2011 at 3:41 PM, Tim Starling tstarling@wikimedia.org wrote:
On 09/06/11 03:25, Łukasz Garczewski wrote:
ConfirmEdit (rationale: every single public wiki I've setup dies without this)
Maybe AbuseFilter would be a better anti-spam choice.
Probably not. It comes by default with no rule sets set up — and would require the system administrator to define complex rule sets by themselves.
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Assuming that we are going to put *some* extensions in, we need to decide which ones.
[..]
Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include.
I'd suggest that you also look at "Suggestions for extensions to be merged into core": http://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_merged_into_core
The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them.
On 8 June 2011 21:01, Casey Brown lists@caseybrown.org wrote:
I'd suggest that you also look at "Suggestions for extensions to be merged into core": http://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_merged_into_core The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them.
Ooh, renameuser would be way useful in intranet land. I've had to twiddle in the database at all ever, which is deeply fragile and annoying ...
- d.
Casey Brown wrote:
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Assuming that we are going to put *some* extensions in, we need to decide which ones.
[..]
Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include.
I'd suggest that you also look at "Suggestions for extensions to be merged into core" on MediaWiki.org.
The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them.
I'd also suggest reading bug 26261.[1] I'm kind of surprised this wasn't mentioned in the opening post given that most replies on this mailing list are echoing the bug's comments.
MZMcBride
On Wed, Jun 8, 2011 at 8:22 AM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
There has been some talk among developers and others about bundling some extensions with the tarball. The new installer supports enabling extensions during installation, so if we're going to do it, I would like to start bundling them with the 1.18 tarball.
This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are "small changes".
I'm assuming our tarball release process currently involves doing "svn export" on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member.
Rob
On Wed, Jun 8, 2011 at 10:25 PM, Rob Lanphier robla@wikimedia.org wrote:
This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are "small changes".
This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things.
I'm assuming our tarball release process currently involves doing "svn export" on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member.
Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already.
Roan Kattouw (Catrope)
On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already.
They've been in SVN for some time (and luckily Tim rewrote them in Python from my older horrid bash code ;)
http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-release/
Basically, we do a SVN export, chop out a few unneeded files, build a tarball and a patch, and GPG-sign them. Also checking out some extensions and dropping them in would not be very difficult to throw in.
Currently the installer's support for extensions is limited; some won't actually set up right, and we don't handle dependencies well, but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial.
It would I think be possible to stash a few things in for 1.18 release with no problem (and no new code, just tossing the existing branched extensions into the tarball) if we wanted to, though they wouldn't be automatically activated at install unless the user actually selects them. Actually making things default would need some more work, and either way we'd want to do a little testing. :)
-- brion
On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber brion@pobox.com wrote:
Currently the installer's support for extensions is limited;
Yes :(
some won't actually set up right,
Examples?
and we don't handle dependencies well,
s/well/at all/
but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial.
I agree :)
-Chad
On Wed, Jun 8, 2011 at 1:43 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber brion@pobox.com wrote:
Currently the installer's support for extensions is limited;
Yes :(
some won't actually set up right,
Examples?
Whatever was listed in bugzilla on that one bug where something didn't run its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc.
and we don't handle dependencies well,
s/well/at all/
exactly. :)
but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial.
I agree :)
\o/
-- brion
On Wed, Jun 8, 2011 at 4:48 PM, Brion Vibber brion@pobox.com wrote:
On Wed, Jun 8, 2011 at 1:43 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber brion@pobox.com wrote:
Currently the installer's support for extensions is limited;
Yes :(
some won't actually set up right,
Examples?
Whatever was listed in bugzilla on that one bug where something didn't run its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc.
That would be bug 28983, which is already fixed in trunk.
-Chad
On Wed, Jun 8, 2011 at 1:50 PM, Chad innocentkiller@gmail.com wrote:
Whatever was listed in bugzilla on that one bug where something didn't
run
its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc.
That would be bug 28983, which is already fixed in trunk.
Objection withdrawn then. :D
-- brion
On Wed, Jun 8, 2011 at 4:30 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already.
Roan Kattouw (Catrope)
They are, /trunk/tools/make-release
-Chad
On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Wed, Jun 8, 2011 at 10:25 PM, Rob Lanphier robla@wikimedia.org wrote:
This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are "small changes".
This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things.
You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change?
I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train.
I'm assuming our tarball release process currently involves doing "svn export" on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member.
Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already.
Even if it's 2-3 hours of work, I still would prefer that a volunteer gets involved in this area. Tim in particular has an overabundance of 2-3 hour tasks.
Rob
On Thu, Jun 9, 2011 at 12:21 AM, Rob Lanphier robla@wikimedia.org wrote:
You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change?
I guess the worst that could happen is that one of the bundled extension breaks core in some way, in which case it's slightly worse because we bundle the extension. Other than that, core is unaffected.
I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train.
I'm not particularly attached to it, and I think we can wait till 1.19 if we want to. I just didn't think your arguments made much sense.
Even if it's 2-3 hours of work, I still would prefer that a volunteer gets involved in this area. Tim in particular has an overabundance of 2-3 hour tasks.
Yeah, that's true. A brief assessment by Tim as to whether this is as easy as I think it is (for someone who speaks Python) would be nice though.
Roan Kattouw (Catrope)
On Wed, Jun 8, 2011 at 6:33 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Thu, Jun 9, 2011 at 12:21 AM, Rob Lanphier robla@wikimedia.org wrote:
You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change?
I guess the worst that could happen is that one of the bundled extension breaks core in some way, in which case it's slightly worse because we bundle the extension. Other than that, core is unaffected.
This.
I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train.
I'm not particularly attached to it, and I think we can wait till 1.19 if we want to. I just didn't think your arguments made much sense.
Also this. I think it's a good idea, but not worth putting aside 1.17 or 1.18 work to make it happen. Even if it didn't happen until 1.20, I don't think it'd be a huge deal...we'd just be maintaining the status quo.
In the long run, I think it makes zero difference whatsoever, as once Real Extension Management becomes a reality, it shouldn't matter at all whether the extension was in the tarball or not--and in fact, I would argue we should keep them *out* of the tarball at that point, to keep download size to a minimum and since hopefully installing extensions would've become painless.
-Chad
Am 09.06.2011 00:37, schrieb Chad:
Also this. I think it's a good idea, but not worth putting aside 1.17 or 1.18 work to make it happen.
I also think we are _not_ in a hurry to add extensions _now_ We should - starting now - take out time to collect (on a MediaWiki page ) opinions what extensions could be candidates for a roll-out.
Thomas Gries mail@tgries.de writes:
We should - starting now - take out time to collect (on a MediaWiki page) opinions what extensions could be candidates for a roll-out.
Done. See [[mw:Possible Tarballs]].
It'd be nice to have a application that would allow people like SemWiki to put together bundles that others could download. Let a thousand tarballs bloom! (As long as I don't have to support them all. ;)
Tim Starling tstarling@wikimedia.org writes:
Remember that most extensions don't have version numbers, there's no way to tell if they're up to date,
Most extensions we're talking about *do* have SVN revison numbers, though.
This doesn't solve the problem you mention here, though:
and there's no way to tell whether they are compatible with the version of the core that is in use.
Finally,
If an extension is bundled and then later merged to the core, there won't be any way to automatically migrate the wikis that used the bundled copy.
Why not? True, there isn't one now. But why can't we create a process for moving extensions to core so that this automatic migration would take place?
Mark.
On 9 June 2011 15:25, Mark A. Hershberger mhershberger@wikimedia.org wrote:
It'd be nice to have a application that would allow people like SemWiki to put together bundles that others could download. Let a thousand tarballs bloom! (As long as I don't have to support them all. ;)
SemanticBundle exists for pretty much this reason. (As someone who's used it to help set up a SMW, it saves *lots* of faff. Though not all of it.)
A more closely supported SMW-in-a-ball would be *most* useful when I need it, and possibly to others ;-)
- d.
Mark A. Hershberger wrote:
Thomas Gries mail@tgries.de writes:
We should - starting now - take out time to collect (on a MediaWiki page) opinions what extensions could be candidates for a roll-out.
Done. See [[mw:Possible Tarballs]].
Please use full URLs in e-mails. I doubt many e-mail clients support interwiki prefixes. ;-) Also, the standard case for wiki pages is sentence case: http://www.mediawiki.org/wiki/Possible_tarballs.
MZMcBride
On 9 June 2011 17:58, MZMcBride z@mzmcbride.com wrote:
Note there's a strawpoll there to indicate tarball users' interest in particular extensions. Go forth and !vote :-)
- d.
On Wed, Jun 8, 2011 at 3:21 PM, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things.
You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change?
Trunk and 1.18 *and* 1.17 already have this ability; all that's required is to drop some directories into the tarball, and they'll be available for selection in the installer.
If any extension doesn't install & work successfully in this manner, don't put it in the tarball.
-- brion
I like to have these "urgently" added in the tarball by default:
* TitleKey !!!! * Cite !!!!
Tom
On 09/06/11 01:22, Mark A. Hershberger wrote:
There has been some talk among developers and others about bundling some extensions with the tarball. The new installer supports enabling extensions during installation, so if we're going to do it, I would like to start bundling them with the 1.18 tarball.
It's a bit sad that we didn't have this ready for 1.17, but there were still a few bugs in the extension installation feature at the branch point. In fact, I see that there was a bugfix merge as late as yesterday.
We can probably include a few popular, well-tested extensions in the 1.18 tarball, as a temporary measure while we are waiting for some better form of extension discovery and management.
I don't think we want this mechanism to become a substitute for merging extensions into the core. Enabling extensions in the installer is not going to be as user-friendly as just having them merged in and enabled by default. I'm thinking in particular about the older half of ParserFunctions, and the usability initiative extensions such as Vector.
So it becomes a question of policy: if an extension is small, popular and uncontroversial, then that's an argument both for merging and for bundling. Bundling is easier for developers, but merging is probably easier for users.
You can go either way. Firefox doesn't ship with any extensions. They merge in features from extensions that are particularly useful, and provide a download interface. Wordpress is one that comes to mind that takes the other approach, it ships with Akismet.
Remember that most extensions don't have version numbers, there's no way to tell if they're up to date, and there's no way to tell whether they are compatible with the version of the core that is in use. If an extension is bundled and then later merged to the core, there won't be any way to automatically migrate the wikis that used the bundled copy.
We can make it easy to install some small set of extensions, but it's not going to be easy to maintain them for a while yet. So there's an argument for keeping the list small and innocuous.
-- Tim Starling
So this is the current list:
* CategoryTree Is this really a feature that most people would use?
* Cite Is this something that most people really use on external sites? how popular (i'm saying this because i'm probably one of the rarer people that don't run/need it on any of my installs)
* Confirm Edit
* DismissableSiteNotice Again, how many people? this seems a suggestion for the sake of it, but i guess its up to other people.
* ExpandTemplates Is this something most sites really need?
* Gadgets * ParserFunctions * Renameuser
* TitleKey Couldn't we just fix search so it was case insensitive compared to needing to bundle something?
* Validator There is really no need for it, unless there is a extenstion that needs it that we are also bundlering we shouldn't just randomly stick stuff in because "it might be nice"
* Vector
* WikiEditor Possibly I guess, although I would actually prefer it in core compared to a extension, I'm not a fan of how it takes a little longer to load and the screen jumps around.
It would probably be nicer to set up ED to record stats on which extensions get downloaded the most and then use that as a starting point for the discussions on what to bundle.
Also have we even looked at security issues side of things? because even if they aren't installed the files will still be sitting there on the server unless someone deletes them from their extensions directory...
I got some more extensions I'd like to see bundeled:
* Poem. Well, actually, I think support for <poem> or <lines> or whatever should be in core.
* SpamBlacklist and AntiBot. Dealing with spam is one of the main problem of a young wiki.
-- daniel
On Wed, Jun 8, 2011 at 10:59 PM, K. Peachey p858snake@gmail.com wrote:
- WikiEditor
Possibly I guess, although I would actually prefer it in core compared to a extension, I'm not a fan of how it takes a little longer to load and the screen jumps around.
Note that the jumping isn't because it's an extension, but rather because of the specific way the toolbar and editor bits get injected and activated.
Merging to core or not would have no effect on that -- it can be fixed while still an extension, or it can remain jumpy in core.
-- brion
On Thu, Jun 9, 2011 at 8:14 PM, Brion Vibber brion@pobox.com wrote:
On Wed, Jun 8, 2011 at 10:59 PM, K. Peachey p858snake@gmail.com wrote:
- WikiEditor
Possibly I guess, although I would actually prefer it in core compared to a extension, I'm not a fan of how it takes a little longer to load and the screen jumps around.
Note that the jumping isn't because it's an extension, but rather because of the specific way the toolbar and editor bits get injected and activated.
Merging to core or not would have no effect on that -- it can be fixed while still an extension, or it can remain jumpy in core.
That's not entirely accurate. If it's in core, we can add some of the container divs in the HTML, reducing the jumpiness.
Roan Kattouw (Catrope)
On Thu, Jun 9, 2011 at 11:18 AM, Roan Kattouw roan.kattouw@gmail.comwrote:
On Thu, Jun 9, 2011 at 8:14 PM, Brion Vibber brion@pobox.com wrote:
Note that the jumping isn't because it's an extension, but rather because
of
the specific way the toolbar and editor bits get injected and activated.
Merging to core or not would have no effect on that -- it can be fixed
while
still an extension, or it can remain jumpy in core.
That's not entirely accurate. If it's in core, we can add some of the container divs in the HTML, reducing the jumpiness.
Simple matter of catching some hooks and outputting divs, and if there aren't the right hooks already, add em.
-- brion
On 9 June 2011 19:14, Brion Vibber brion@pobox.com wrote:
Note that the jumping isn't because it's an extension, but rather because of the specific way the toolbar and editor bits get injected and activated. Merging to core or not would have no effect on that -- it can be fixed while still an extension, or it can remain jumpy in core.
That jumping is one of the biggest pains in the goddamn ass when I'm trying to edit Wikipedia.
(It appears my 1Mbit connection is not fast enough for Wikipedia, as my 20MBit work connection doesn't have the same problem, finishing the jumping far quicker ...)
Is there anything I can do to alleviate this bloody annoying problem?
- d.
David Gerard wrote:
On 9 June 2011 19:14, Brion Vibber brion@pobox.com wrote:
Note that the jumping isn't because it's an extension, but rather because of the specific way the toolbar and editor bits get injected and activated. Merging to core or not would have no effect on that -- it can be fixed while still an extension, or it can remain jumpy in core.
That jumping is one of the biggest pains in the goddamn ass when I'm trying to edit Wikipedia.
(It appears my 1Mbit connection is not fast enough for Wikipedia, as my 20MBit work connection doesn't have the same problem, finishing the jumping far quicker ...)
Is there anything I can do to alleviate this bloody annoying problem?
As I recall, the old toolbar had this exact same problem. The only difference was that it was so much smaller in code size that it wasn't nearly as noticeable, especially on a fast connection. The English Wikipedia implemented a solution that pre-set the height of the toolbar in CSS, so when it finally loaded, there would be no jump. More info about this trick: http://en.wikipedia.org/w/index.php?oldid=259876614#Jumping_edit_window.
I'm not sure if the same trick can work for the new toolbar, as the new toolbar doesn't have a consistent height. The height fluctuates depending on which sub-modules have been expanded previously. This could probably be fixed by loading the toolbar earlier, though?
MZMcBride
On Thu, Jun 9, 2011 at 12:11 PM, MZMcBride z@mzmcbride.com wrote:
I'm not sure if the same trick can work for the new toolbar, as the new toolbar doesn't have a consistent height. The height fluctuates depending on which sub-modules have been expanded previously. This could probably be fixed by loading the toolbar earlier, though?
I'm sure folks can figure it out -- but hopefully in another thread. :)
-- brion
wikitech-l@lists.wikimedia.org