[pmwiki-users] How to submit patches to PmWiki?

Petko Yotov 5ko at 5ko.fr
Sat Jun 27 16:10:12 CDT 2009

On Saturday 27 June 2009 01:08:11 Simon wrote:
> I have noticed that PITs entries don't seem to be much exposure (eg on
> mailing lists), discussion (eg comments on the page), or support (eg
> votes).

PITS entries are public, anyone is welcome to post an opinion, a suggestion or 
a comment. If there are not many discussions or votes could that be because 
few people are concerned with the changes that someone wants?

> I'd like to see a bit more boldness and vitality in the PmWiki 
> community, the pace of change when I started using PmWiki was exciting,
> and encouraged me to hop on board the train.
> I worry that we have changed to an era where we should be more progressive,
> and now have a philosophy of being overly conservative about changing the
> core.

The "PmWiki/PmWikiPhilosophy" #3 hasn't changed for a long time (ever?), as 
far as I know. We don't add features without a demonstrated specific needs 
and usefulness for a number of sites. Quote :
  it's hard to change a poorly designed feature once
  people have built a lot of structure based on it.

Again, one way to find out if it is the case, is to have a discussion with 
arguments and votes of real people from the community.

> Perhaps we have an opportunity for the committers to lead a discussion
> about the road map for the core, and for extensions.

I am open to such a discussion. I'll keep doing what the community requires.

> I'd like to see more submissions from code submitters taken on board and
> acted upon.
> Particularly where those enable recipe writers to improve there recipes,
> and where they fix identifiable issues in the core.

I have said many times, if a recipe cannot be enabled because the core lacks 
some hook or switch for it, we can add it quickly (with common sense).

> While I wouldn't like PmWiki to because a swiss army knife (one of the
> reasons I chose it), on the other hand I didn't want UseMod (as an example
> of a low feature low change wiki) either.

The current PmWiki core has an extraordinary amount of features, some of which 
cannot be seen anywhere else. Do anyone use them all?

> When it gets to the point that I have to individually select and install 20
> or so recipes to get the functionality I want I have to wonder if the
> balance has swung too far in the other direction.

When you "hopped on board the train", did you need to install all these 
recipes to get the functionality you want? How many of the recipes existed at 
that time?

Everyone who needs a bundle of 20 or so recipes should feel free to create it. 
And to support it, now and in the future.

> I don't have a problem with changing PmWiki behaviour, or removing some
> backward compatibility between major releases, especially if it supports a
> clean code base, and a more consistent experience for authors.

While this can be discussed, the next PmWiki 3.0 major release could take some 
time. The PmWiki Philosophy #5 however states that a pmwiki should be easy to 
maintain between upgrades.

> I recognise that adding to the core adds to complexity, and the the load of
> the maintainers -

Complexity means slowness and more potential bugs, and even more complexity to 
maintain things working after some changes in other parts of the code.

> my suggestion, increase the community of submitters. 

There are at least two people who could (and should) become core developers, 
and a number of others who could be webmasters.

I feel, however, that they should adhere to the PmWiki Philosophy which is the 
contract between the developpers and the community of users. 

Or isn't it?

> I also recognise that in in some areas - eg images - there are a number of
> great recipes, in others there are exactly one that do a good job of
> enabling some 'basic' functionality,
> I can think of several, but examples to me (off the top of my head) are
> attachtable <http://www.pmwiki.org/wiki/Cookbook/Attachtable>,
> rowspan<http://www.pmwiki.org/wiki/Cookbook/RowspanInSimpleTables>,
> and the jt patch to
> ExcelPaste<http://www.pmwiki.org/wiki/Cookbook/Tabtable-jt>,
> all of which, to me, add what I consider to be needed and basic
> functionality.

I do use Attachtable, but a simpler, heavily stripped down older version. 
Recipes with that many features should stay in the Cookbook. (This is an 
example, there are many other excellent recipes.)

I have never needed to use rowspan in simple tables or ExcelPaste, and I have 
a number of pmwikis running for a few years. 

That is an example how a feature some users require as a "basic functionality" 
may be absolutely irrelevant for other users. That's why we need to discuss 
in order to avoid the "Creeping Featuritis" of the core.


> I also do appreciate the responsiveness of the current committers and the
> size of the task facing them, its partially for this reason that a good
> discussion from the PmWiki community is required.

I am willing to do whatever the community agrees that is required. (Or Pm.)

> PmWiki is a fantastic product, lets keep it that was through keeping it
> active, evolving, and through the participation and contributions of us,
> its community.

Sorry if it feels it isn't active and evolving. Even if in the last two 
releases there have been more fixes than in the previous 19 or so months 
(previous 2-3 years for the core documentation).

> thanks

Thank you Simon.

> 2009/6/27 Chris Cox <ccox at endlessnow.com>
> > I think there are two sides... I like PmWiki as a set of lower level
> > tools... a toolkit upon which we can build extensions (we often call
> > these recipes).
> >
> > The other side are those looking for a feature rich deployment platform
> > where little to no configuration (even downloading a "recipe") is
> > required.

If there is a real need for an installation with little or no configuration, 
someone should create such a bundle.

> > So, with that said, I think the idea of "recipes" in the core is
> > possible, but I'd like to see it done in a way that does not require
> > adding bloat to the base PmWiki.  Perhaps some automated way to pull in
> > "signed" extensions afterward (?)... or maybe a large add-on download.
> > Of course, there will also be the normal "recipe" way of pulling in othe
> > rextensions (along with the problems and conflicts that they might
> > cause).

There are some practical problems when adding extensions inside the core.
* Who should select them?
* Who should review them for inclusion?
* Who should review (consistency, security, features, etc.) each new version 
which is produced by the developper?
* How should we deal with competing recipes? Who decides which one we support, 
if it is impossible or redundant to have both?
* Who should make sure the recipes still work in newer versions of the PmWiki 

Is the answer to all these questions "Petko"?

> > So, for example, I download PmWiki, which allows ME to build great
> > things.  But let's say there's feature-full blogging package that is now
> > part of the core (a "signed" extension).  And it has all the bells and
> > whistles of the major blogging packages out there, perhaps is close to
> > the size of the PmWiki core itself.  That piece could be optionally
> > added using some kind of automatic PmWiki package install command... or
> > it might be part of the larger inclusive extension package that I could
> > install.

We could possibly find a new way to install recipes, easier than how it is 
done today. And even to configure both the core and these recipes.

> >
> > Obviously, things like this would require some work.
> >
> > Bug fixes though are fine.  And additions to the core that make it a
> > better more flexible toolkit is also fine.

This is our current policy... :-) Bugs are fixed as quickly as it is 
practical, new hooks are added too, hopefully with common sense...


More information about the pmwiki-users mailing list