Good evening,
Hashar and me discussed about the Vector extension this morning on #wikimedia-tech and we wonder if the code shouldn't be merged to core.
Rationale: Vector is the main design of our product and the Vector extension contains enhancement for this skin.
Core of MediaWiki, or core of the Vector skin? I am fine with doing that for the skin, but I would keep it out of MediaWiki. The design is going to change, and lots of folks use different skins and don't use the extension.
maiki
On 02/04/2013 06:02 PM, Sébastien Santoro wrote:
Good evening,
Hashar and me discussed about the Vector extension this morning on#wikimedia-tech and we wonder if the code shouldn't be merged to core.
Rationale: Vector is the main design of our product and the Vectorextension contains enhancement for this skin.
Hey,
if the code shouldn't be merged to core.
I have no real opinion on if this should happen or not,. though if it does, I think it'd be better to bundle it as the extension it is now rather then merging it into core. This keeps the code nicely separated and core more "lean".
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
On 05/02/13 13:02, Sébastien Santoro wrote:
Good evening,
Hashar and me discussed about the Vector extension this morning on #wikimedia-tech and we wonder if the code shouldn't be merged to core.
Rationale: Vector is the main design of our product and the Vector extension contains enhancement for this skin.
I didn't think it should have been an extension to start with, and I asked for it to be merged when the Usability Initiative was concluded. So yes, I think it should be merged, better late than never.
On 06/02/13 00:12, Matma Rex wrote:
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
That sounds like a good reason to merge it.
-- Tim Starling
On Tue, Feb 5, 2013 at 10:53 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
I have no real opinion on if this should happen or not,. though if it does, I think it'd be better to bundle it as the extension it is now rather then merging it into core. This keeps the code nicely separated and core more "lean".
Cheers
(Not specificity at Jeroen, but a common trend that has popped up as of late) Can we not just keep going "lets stick it in the installer" for everything when someone objects to it going in core, If we don't want "junk" in the core to keep it "lean" and "minimalist" (insert other favourite word here) the same standard should also apply to the installer otherwise we are just pushing the issue of feature overload and cruft from Point A to Point B.
Going foward, I think we should work on developing some guidelines on when things should go in core vs extensions (and/or the extension bundled in the installer).
On Tue, Feb 5, 2013 at 11:12 PM, Matma Rex matma.rex@gmail.com wrote:
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
-- Matma Rex
Well now would probably be a good time to start working on the list of the features, and discuss what people want (weather its certain parts in core or whatnot), what is broken and what is undesired and go from there. and look at the best solution for the outcome from there.
On Wed, 06 Feb 2013 04:31:13 +0100, Tim Starling tstarling@wikimedia.org wrote:
On 06/02/13 00:12, Matma Rex wrote:
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
That sounds like a good reason to merge it.
I'm not saying I'm against that, not at all. I'm just noting that Vector is... weird, and it might be harder than it looks. For example, the new editing interface cleanup now live on en.wiki is for some bizarre reason part of Vector, and it's completely not compatible with other wikis at all right now.
On Wed, 06 Feb 2013 06:49:56 +0100, K. Peachey p858snake@gmail.com wrote:
Well now would probably be a good time to start working on the list of the features, and discuss what people want (weather its certain parts in core or whatnot), what is broken and what is undesired and go from there. and look at the best solution for the outcome from there.
Now this is simple, I think; we take everything that is enabled by default right now and move it to core (that would be collapsible tabs and collapsible nav), and completely kill the rest (that would be some weird features which you can't even opt-in to on WMF wikis and edit warning functionality which basically breaks stuff all over in my experience).
don't merge anything into core pls. rip the stuff out of core and make extensions from them, and finally, please make core a lightweight and faster
On Wed, Feb 6, 2013 at 8:34 AM, Matma Rex matma.rex@gmail.com wrote:
On Wed, 06 Feb 2013 04:31:13 +0100, Tim Starling tstarling@wikimedia.org wrote:
On 06/02/13 00:12, Matma Rex wrote:
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
That sounds like a good reason to merge it.
I'm not saying I'm against that, not at all. I'm just noting that Vector is... weird, and it might be harder than it looks. For example, the new editing interface cleanup now live on en.wiki is for some bizarre reason part of Vector, and it's completely not compatible with other wikis at all right now.
On Wed, 06 Feb 2013 06:49:56 +0100, K. Peachey p858snake@gmail.com wrote:
Well now would probably be a good time to start working on the list of the features, and discuss what people want (weather its certain parts in core or whatnot), what is broken and what is undesired and go from there. and look at the best solution for the outcome from there.
Now this is simple, I think; we take everything that is enabled by default right now and move it to core (that would be collapsible tabs and collapsible nav), and completely kill the rest (that would be some weird features which you can't even opt-in to on WMF wikis and edit warning functionality which basically breaks stuff all over in my experience).
-- Matma Rex
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 02/06/2013 03:53 AM, Petr Bena wrote:
don't merge anything into core pls. rip the stuff out of core and make extensions from them, and finally, please make core a lightweight and faster
The speed of MediaWiki isn't directly related to the amount of code in core. Speed is all about keeping the average code path to execute any given request short.
Thus, we can ship more extensions and languages with MediaWiki without affecting anything but the download size of the tarball and the amount of space that MediaWiki takes up on disk.
This doesn't mean we shouldn't care about size -- I think there is some merit to the idea of shipping a minimal MediaWiki. With the availability of Composer and extension installers, we're beginning to bootstrap our way to a good way for the end user to add on to xyr MediaWiki installation.
But "faster MediaWiki" isn't an argument against bundling code.
Mark
On 6 February 2013 18:42, Mark A. Hershberger mah@everybody.org wrote:
On 02/06/2013 03:53 AM, Petr Bena wrote:
don't merge anything into core pls. rip the stuff out of core and make extensions from them, and finally, please make core a lightweight and faster
The speed of MediaWiki isn't directly related to the amount of code in core. Speed is all about keeping the average code path to execute any given request short.
Rather than absolute size, we should care about core that is modular and has well-defined interfaces. Moving stuff to extensions is one way to encourage this, as then the functionality cannot be relied on or it can be replaced with an another extension.
More refactorings and rewrites are needed (like ContentHandler) to get MediaWiki back to enabling the development of new ideas rather that limiting that. At the same time constantly changing interfaces and breaking existing extensions will annoy people depending how much we will put effort into keeping backwards compatibility. Can't please everyone.
-Niklas
-- Niklas Laxström
On 02/06/2013 01:14 PM, Niklas Laxström wrote:
More refactorings and rewrites are needed (like ContentHandler) to get MediaWiki back to enabling the development of new ideas rather that limiting that. At the same time constantly changing interfaces and breaking existing extensions will annoy people depending how much we will put effort into keeping backwards compatibility. Can't please everyone.
You're right, you can't please everyone, but we should at least have some sort of support for legacy interfaces.
That, and coordinating with the authors of the impacted extensions would also help.
Hey,
I think Niklas his comment is spot on:
Rather than absolute size, we should care about core that is modular
and has well-defined interfaces. Moving stuff to extensions is one way to encourage this, as then the functionality cannot be relied on or it can be replaced with an another extension.
MediaWiki is currently closer to being a ball of mud then a set of core components nicely separated and working together via clean interfaces. We have so many components that could just as well be independent from the rest of the codebase, but they are not. Loose from the direct technical cost of this, it also prevents reuse outside of MW and prevents using other third party libraries from being used for those components rather then custom MW code. Though we can clearly not just get rid of this legacy (short from rewriting MW), we can encourage independent code and clean interfaces.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 02/06/2013 02:24 PM, Jeroen De Dauw wrote:
MediaWiki is currently closer to being a ball of mud then a set of core components nicely separated and working together via clean interfaces.
I don't disagree. But we're also a strange amalgamation of volunteers, administrators of wikis, consultants providing services for customers, and WMF-employed developers.
I agree that Niklas and you are talking about something that should be done. The problem is: who is going to do it? How is it going to be accomplished?
For that matter, what is "it"?
We have so many components that could just as well be independent from the rest of the codebase, but they are not.
With the introduction of Composer, we can begin to think about breaking MediaWiki up into discrete components.
Perhaps that is a good way to start thinking about it?
I think extensions can be "Composed" with MediaWiki right now. It wouldn't be hard to move almost entire languages directory off to "composable" bits (though Niklas and the other TWN folks might kill me for even suggesting that, given how much they had to suffer in the move from svn to git).
We would still want a legacy tarball, but even that could be composed at the time of distribution.
Hey,
For that matter, what is "it"?
Let's assume "it" means not repeating the tight coupling and badly defined interfaces mistakes made in the past:
The problem is: who is going to do it?
How is it going to be accomplished?
Everyone that's writing new code or refactoring old code. These principles make sense to follow in pretty much any development context that is not some one-off.
No magic involved. If we all pay attention to these points, the codebase as a whole will gradually increase in quality. There is no need for someone to go rewrite things, though if someone feels like doing that, it'll certainly hasten the process.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Wed, Feb 6, 2013 at 4:58 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
No magic involved. If we all pay attention to these points, the codebase as a whole will gradually increase in quality. There is no need for someone to go rewrite things, though if someone feels like doing that, it'll certainly hasten the process.
+1. With the important caveat that incremental improvements are always easier to review and merge than omnibus rewrites.
-Chad
Le 06/02/13 20:24, Jeroen De Dauw a écrit :
MediaWiki is currently closer to being a ball of mud then a set of core components nicely separated and working together via clean interfaces. We have so many components that could just as well be independent from the rest of the codebase, but they are not. Loose from the direct technical cost of this, it also prevents reuse outside of MW and prevents using other third party libraries from being used for those components rather then custom MW code. Though we can clearly not just get rid of this legacy (short from rewriting MW), we can encourage independent code and clean interfaces.
We could probably keep our legacy interfaces and base them to cleaner one that could be reusable by third parties or even come from third parties (Symfony components comes to mind).
The includes/libs/ directory is more or less meant for that.
I would prefer we do not break back compatibility, it is already hard enough to upgrade a wiki having several extensions.
On 06/02/13 19:53, Petr Bena wrote:
don't merge anything into core pls. rip the stuff out of core and make extensions from them, and finally, please make core a lightweight and faster
There are lots of lightweight wiki engines to choose from. MediaWiki was never going to be among them, it had enough features in version 1.0 to put it in the heavyweight class.
Many design decisions made since then (for instance, the introduction of the resource loader) have favoured features over support for small installations.
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence. I don't think it can ever compete with TiddlyWiki or UseModWiki in their respective niches.
-- Tim Starling
On Wednesday, February 6, 2013 at 3:58 PM, Tim Starling wrote:
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence.
What would it take?
-- Ori Livneh
Ori Livneh wrote:
On Wednesday, February 6, 2013 at 3:58 PM, Tim Starling wrote:
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence.
What would it take?
Off-hand, it looks like:
* better enterprise support, * granularized read restrictions, * granularized write restrictions, * a proper visual editor, and * a proper graphical configuration interface.
cf. http://www.atlassian.com/software/confluence/features
MZMcBride
On Thu, Feb 7, 2013 at 1:23 AM, MZMcBride z@mzmcbride.com wrote:
Ori Livneh wrote:
On Wednesday, February 6, 2013 at 3:58 PM, Tim Starling wrote:
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence.
What would it take?
- a proper graphical configuration interface.
I'll just use this to mention https://www.mediawiki.org/wiki/Extension:Configure. It seems like something that, if nurtured into a stable form, would add great value to mediawiki, regarding the point quoted above.
I don't think people are arguing to keep it lightweight like Tiddly or UseMod but rather on a similar platform on what we already have and to keep the core in a position where it can have features that would be widely used by most installations and the "cruft" that is more rarely used to be housed as extensions.
On Thu, Feb 7, 2013 at 9:58 AM, Tim Starling tstarling@wikimedia.org wrote:
There are lots of lightweight wiki engines to choose from. MediaWiki was never going to be among them, it had enough features in version 1.0 to put it in the heavyweight class.
Many design decisions made since then (for instance, the introduction of the resource loader) have favoured features over support for small installations.
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence. I don't think it can ever compete with TiddlyWiki or UseModWiki in their respective niches.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 07/02/13 11:16, K. Peachey wrote:
I don't think people are arguing to keep it lightweight like Tiddly or UseMod but rather on a similar platform on what we already have and to keep the core in a position where it can have features that would be widely used by most installations and the "cruft" that is more rarely used to be housed as extensions.
That wasn't how I interpreted Petr's comment, since the Vector extension is small and has several features which are uncontroversial and should be useful for almost all MediaWiki installations.
Petr said "don't merge anything into the core", not "don't merge rarely-used features into the core".
-- Tim Starling
On Tue, Feb 5, 2013 at 10:31 PM, Tim Starling tstarling@wikimedia.org wrote:
On 05/02/13 13:02, Sébastien Santoro wrote:
Good evening,
Hashar and me discussed about the Vector extension this morning on #wikimedia-tech and we wonder if the code shouldn't be merged to core.
Rationale: Vector is the main design of our product and the Vector extension contains enhancement for this skin.
I didn't think it should have been an extension to start with, and I asked for it to be merged when the Usability Initiative was concluded. So yes, I think it should be merged, better late than never.
Yes, and you weren't alone in thinking (or saying) that.
-Chad
On 02/05/2013 10:31 PM, Tim Starling wrote:
On 06/02/13 00:12, Matma Rex wrote:
Vector is a weird mess of extensions to the skin, extensions to general functionality, and unused broken scripts. Merging it properly would require some work and some deleting.
That sounds like a good reason to merge it.
I agree. Merging it could be a good opportunity to remove cruft.
Matt Flaschen
There seems to be consensus about this, so I created https://bugzilla.wikimedia.org/show_bug.cgi?id=45051 for dealing with the details of the operation.
wikitech-l@lists.wikimedia.org