[pmwiki-users] Any hope for 2.2.0 stable release?

Radu Luchian radu at monicsoft.net
Thu Jan 15 14:09:37 CST 2009

Definitely yes to releasing a new stable version, even if some features
aren't ready.
But NOT if that requires too much time to be added to anyone's schedule for
pruning code.

About the rest of the discussion,... Jeez.
I would look up some Dilbert cartoons on decisions by committee, but I have
other things to do right now :)

In a word, Pmwiki is just fine, and just stating that it's backward
(laggard, in need of unnecessary development just to add extra overhead for
OOP or some such), doesn't make it so. Less development in a product that
boasts so much functionality and such flexibility as Pmwiki, is just a
measure of stability.

More of my opinions below.


On Thu, Jan 15, 2009 at 12:08 PM, Henrik Bechmann <
henrik.bechmann at sympatico.ca> wrote:

>  My own installation of PmWiki will probably serve as is for another couple
> of years, but then it'll really start to get tired without further
> development.

What's with all this need for development? I find the current model used
just dandy. If I need something new, I develop. But I like simplicity, and I
try to keep functionality and resources used to a minimum. In the beta core
I tend to undefine functions more than add new ones. So adding stuff to the
core and even more, to the default setup sort of goes against the PmWiki

If you need something that's not yet available, discuss, implement and if
you have the time, release as recipe.

If you have problems with the docs, talk it over on one of the lists, then
go ahead and make the changes.

What's with the need for formal organization?? Open Source is great for its
informality. Got five minutes? Do something. There's no deadline, no
headache and very limited stress.

But that gives us time to get organized for moving forward.

Jeez. Do you suffer from the effects of too many management courses? ;)

> The question is, is there sufficient interest and energy to assemble an
> effective group.

The group is as effective as we have time for.

> What I see:
> Step 1: declare current release out of beta

It's not only a matter of declaration... SomeONE (PM obviously) has to use a
sizeable chunk of his time to make sure the code and docs are consistent
enough for a release.

And I say ONE because all decisions by committee (like OOP, BTW), suffer
from a heluva lot of overhead and in the end require far more resources than
if they are done by one person. If PM needs help with something, he'll ask.

> Step 2: identify a (for real) webmaster to take responsibility for
> pmwiki.org

I used to like Wikipedia a lot before they introduced the commitee system.
Now we got censure and repeated requests for funding. All developers are
webmastering the wiki site whenever we can. We identify ourselves by doing
stuff. Which is the point of a wiki.

> Step 3: create a development.pmwiki.org subsite, where we can set up a
> wiki to begin a formal planning process (and set up a TRAC repository for
> the current code base)

What's wrong with the current svn? Why do we need to spend more server
resources on a python web interface?

Step 4: fire up pmwiki-devel for *lively* discussions about related issues:
> planning, feature discussions, organization, decision making, etc.

Go ahead. Organize :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090115/aee75f2f/attachment.html 

More information about the pmwiki-users mailing list