I didn't know whether you were serious about splitting off the SMW PS class into its own extension, but clearly you are - and you might want other functionality split off as well, like maybe an #info tag extension. I don't know whether it's worth having a full discussion about the philosophy of extension size on this list - there was a long discussion about this topic on the wikitech-l mailing list last month that covered the main points, which anyone can see here:


This is a big topic, but I'll just say that the view of MediaWiki extensions as libraries or packages is, in my opinion, not an accurate description. If there were a true "package management system" for MediaWiki, that everyone could use easily, it might be a different story, but at the momentthere isn't. So many people end up maintaining many different versions of MediaWiki and many different combinations of extensions, each with their own versions; and the more extensions there are, the more work it is for admins and the more things that can go wrong - and by extension, the more work it is for developers who have to document all the installation steps, detail all the version compatibility issues, and help with debugging every time something goes wrong.

But, back to this specific issue: what exactly is the liability of having this PS SMW class/file contained in SMW? You and James have both said that it would cause problems, but I don't see how. Even in the worst case, where the code in the class is awful and doesn't work at all, as long as it doesn't affect the normal running of SMW it shouldn't be an issue for SMW developers. If you see a bug report or email relating to the SMW PS code not working, you can either ignore it or assign it to whoever is maintaining Page Schemas (at the moment, sending it to either me or Yury would be fine). Is it really an issue that one or more classes in SMW are not covered by unit tests, other than an aesthetic one?


On Sat, Aug 10, 2013 at 2:25 AM, Jeroen De Dauw <jeroendedauw@gmail.com> wrote:

> I can think of a number of things that SMW does, unrelated to its core goals:

SMW core could indeed be more lean.

Now, maybe the right solution is to split off all of this extra stuff into one or more other extensions, as was done with DataValues (and perhaps with Diff and the rest - I don't know if those started out as SMW code).

Diff is not related to SMW in any way.

DataValues is based on SMW code though not yet used directly by SMW. That is something planned though.

> Personally, though, I think the better solution is to just view SMW as an extension that does a lot of things, in the back-end and interface, related to the storage of semantic data.

It is important to differentiate between the developer and the user views on this. From a development perspective it makes a lot of sense to have these things nicely kept separate.

From a user perspective certain combinations of packages tend to be desired. This is why software tends to have a build process, so the selection of functionality needed by the user can be put into an easy to use bundle that appears to be one piece of software to the user. And since different users have different needs, you'd typically have a few variants of this. For instance "SMW core" with just the core stuff, "SMW plus forms and related stuff", and "ALL of the SMW things". Right now we are not doing an as good job at providing such things as we could. SB is a step in the right direction, though still far from what we could have.

From a dev perspective it is important to keep district things separate, to avoid not needed dependencies creeping in, and to reduce maintenance costs. Since we have not all that much manpower for maintenance, we should be very careful about this.

Some factors that are relevant in determining if something should go into SMW core are size and code quality. In case of the Admin Links hook, which is just a few lines of simple code, there is not all that much reason to move it out. There is more PS code though, and it is more complex. Plus it has design issues which combined with the lack of tests make it a liability.

In the case of the PS code, I'm not convinced that having a "PSSMW" extension would be to much of an issue even without improving our current build and publishing process. After all, there are many much smaller MW extensions out there.


Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3

WikiWorks MediaWiki Consulting http://wikiworks.com