Item12725: Needed: "batteries included" Foswiki distribution(s)

In Item12721 (Support multiple attachments at one time), VickiBrown argues that this feature should "just work" (as it has in TWiki for several years). Specifically, she doesn't want sysadmins to have to research, download, install, and configure a plugin just to get this (seemingly minor) enhancement.

In his responses, MichaelDaum argues that TopicInteractionPlugin has the desired capability (and many more), so sysadmins should simply install it and move on. He then goes on to argue for a particular approach to distributions:

The standard Foswiki distribution will then be a minimal one with additional distributions on the side, more tailored to specific needs. (I often call it the bare-bones distribution.)

This approach is used in various software communities (eg, Emacs, Debian Linux, Perl, X11). It is highly configurable and meets the needs of experts very well. However, it's not the approach taken by Mac OS X, Perl5i, or Ubuntu Linux; instead, they provide a "batteries included" distribution that meets the needs of most users but allows further expansion and tweaks. Although I've been using and administering Unix systems since V7 (1983), I find that this approach works very well for me. For example, I use Mac OS X and (if need be) Ubuntu Linux.

Because VickiBrown maintains our Foswiki and TWiki installations, I can ignore most wiki configuration issues, however gnarly. However, this solution isn't applicable to most sites that are "trying out" Foswiki. They don't have a local Foswiki gardener and may not want to hire one. So, I'd like to propose that Foswiki create, package, and promote at least one "batteries included" Foswiki distribution. The idea is that just about anyone should be able to download and install it, possibly clicking a configuration setting or three, and get started.

But there are 300+ Foswiki plugins (I hear you say :-); which ones should be included in the distribution? My take, FWIW, is that they should all be included, unless they are known to be problematic, eg:

• affect standard Foswiki behavior, even when turned off

• have known bugs, load order issues, OS dependencies, etc.

• require large and/or complicated external software
  (Doxygen, Gnuplot, LaTeX, MySQL, SOLR, ...)

• are ridiculously large (eg, multiple megabytes)

Such a distribution would certainly be larger than a "bare-bones distribution". However, Perl code is pretty compact, and we're avoiding the real monsters, so it wouldn't have to be all that big. It could also be released relatively infrequently (eg, annually), taking advantage of the knowledge (eg, best practices, bug reports) contributed by "early adopters".

Ducking...

-- RichMorin - 21 Jan 2014

Rich, I agree, and thats why I made the debian repository. It is pretty darned simple to run something like

apt-cache search foswiki | xargs apt-get install

and thus have everything installed, and even have most well defined external dependancies installed for you - like imagemagik etc.

the hard work, is that someone needs to test what works, what doesn't work with what else, and so on - and from there, make a smal script to auto-enable / configure things.

nice suggestion - and assuming there are people who need this, then you won't have trouble finding people to help test

-- SvenDowideit - 21 Jan 2014

Are there any other products out there that actually do something similar ... shipping all user contributed extensions? It seems to me that presenting the admin with a list of hundreds of possible plugins in a configure enable checkbox list would be horribly confusing.

Also, the only extensions that can be enabled/disabled are the plugins. Anything like Contribs and AddOns just install stuff into directories with various ways of enabling. Some are "just there", some require settings, like SKIN= or COVER= overrides, etc.

So here's a list of questions

System topics

Do we need to hide them? Currently any (most) installed extensions end up with a System, and maybe test examples in Sandbox. This would be most confusing to the user trying to figure out how to use Foswiki. We've even seen that on Foswiki.org, where there are only a couple of extensions installed that are not active.

FollowsReleaseProcess

Do we have to put extensions under the release process to include them in the distribution? How does the RM decide when extensions are ready to release? No blockers open? No failing tests?

General quality

We have a real mix of extensions out there. Some monkey patch things, some call functions outside of the Foswiki API, few have unit tests.

I would never want to see everything and the kitchen sink in a single foswiki distribution. What might make sense though is a decision to include a small subset of modern extensions added to the list of default extensions included in the distribution, provided that their developers agree to put them under release control, add unit tests and translations. TopicInteractionPlugin sounds like a good candidate, along with its dozen dependencies.

The new ConfigurePlugin being developed also might make it easy to have a wizard page for families of related extensions, where dependencies are all checked and they are enabled / configured as one. Otherwise it sometimes is a bit confusing to the admin to figure out which plugins to enable, and which settings to override.

In any event, this needs a feature proposal.

-- GeorgeClark - 21 Jan 2014

Installing all and every plugin does not make sense. It is important to install only those plugins that make sense with regards to the scenario. There are at least a dozen different scenarios where different sets of plugins are required to implement specific requirements. Looking at plugins only isn't the right approach to come to a Foswiki that fits a specific need properly.

We probably don't want monolithic releases, like TikiWiki, I guess.

The discussion should be driven by "FoswikiFor" and only then would you decide on a distribution coming with a specific set of plugins. You might very well find out that you are in need of a specific feature not yet there, e.g. to have activity streams, micro blogging, like, follow, dynamic teams, group invitation, rating, recommend content, a reputation system, whatever. Some of these features have consequences for other sub-systems of Foswiki, like sorting search results by number of likes, promote recommended readings higher in the search order. These problems can't be solved in a single plugin alone. The solution clearly spans multiple components that interact with each other.

-- MichaelDaum - 21 Jan 2014

There is a major difference between supplying software as part of a distribution and enabling it by default. I am in violent agreement with MichaelDaum that different users will have different needs. I just want to make it easier for users to set up and try out different configurations to meet these needs.

By including stable versions of all of the small-to-moderate size plugins, and providing some sort of "wizard" (eg, to select among pre-defined configurations), we could make Foswiki considerably easier for new administrators. This would also make it easier for users to get help, eg: "I'm using the Foo configuration and the Bar plugin fails."

To make things even better, we could have built-in testing for random assortments of plugins. See Item12728 (Automated configuration testing notions) for details.

-- RichMorin - 23 Jan 2014

Commenting is disabled while not logged in