[pmwiki-users] Pre-announcing 2.2.0 non-beta release, new release manager

Peter Bowers pbowers at pobox.com
Tue Jan 20 10:17:21 CST 2009


> > [...]
> > Anyway, my point in this is just to point out that we already do this
> with
> > pmwiki with authuser.php -- it's just a question of expanding the set of
> > recipes that are included and figuring out QA procedures and etc.
> 
> Then my counter-point is that we *don't* already do this with
> authuser.php, precisely because of the difference in QA procedures.
> Put another way:  You've hand-waved away the hardest part of
> the question.  :-)

Have you seen the cartoon with the mathematicians doing an very complicated
proof on a blackboard and in the center they have written "magic occurs
here" to get them over that hurdle.  That's what I'm doing... :-)

> Here are some questions that will need answering:
> 
> 1.  Once a recipe is adopted into the basic distribution,
> who is responsible for maintaining that recipe and verifying
> that it works with subsequent versions of PmWiki?

Firefox handles this by disabling add-ons that have not been specifically
tested for the new version.  Obviously it becomes a pain for developers if
there is a monthly release schedule, but it's probably the only real solid
way of maintaining relatively proveable reliability...?  

I think for a recipe to be even considered for inclusion as a bundled part
of core the recipe author would have to be willing to produce a test suite
that can be run automatically as part of release preparation.[1]  This would
take some thought in terms of setting up an appropriate infrastructure for
this type of testing, but it would be a significant boon to recipe authors
and the users as well...  Yes, inclusion in core would be a significantly
increased burden on the developer of the recipe -- there's no way around
that...  If the developer stops contributing then that's when the awkward
part occurs, I guess -- at that point there needs to be someone else
stepping up to the plate or else that recipe becomes unbundled and you have
some unhappy users (but it would be clearly documented in release notes and
so administrators would make a deliberate choice about it).

> 2.  If a new version of a recipe is published in the Cookbook,
> does that imply we need an immediate new release of PmWiki
> to incorporate the new version of the recipe?

If we're looking at a monthly release schedule I wouldn't think you would
need something more often.  Obviously if there is a critical security update
then it would necessitate a new release, but I wouldn't think that would
happen more than once every year or so?  (That's a guess...)

> 3.  If we don't issue a new release, how do we manage the
> mismatch between recipe versions in the cookbook versus
> recipe versions in the distribution?

I'm assuming that more experienced administrators would continue to install
new versions of recipes as they have been doing.  Release notes would be the
tie-in to make sure that you don't have actual conflicts (release X of this
recipe doesn't work with release Y of core), but that's no different than it
is right now.  Basically the bundling gives the benefit of the first-time
installer and those who want a periodic update without reading up in detail
on every recipe they've installed...  For administrators that need the new
functionality or the just-released bug fix, they can figure it out just as
they do now.  In other words, bundling doesn't solve all the world's
problems, but it makes life a lot easier for a significant group of people
and increases pmwiki's usability by lowering the threshold of technical
expertise.

> 4.  In many cases, I don't really want this to become a
> "winner takes all" situation whereby one recipe's approach
> (adopted into the distribution) tends to exclude other
> equally-worthy candidates from consideration.

Yes, to my mind this might be the more "magic occurs here" point.  Deciding
on a given recipe to fulfill specified functionality when there are 3
recipes that do it in different ways...  That's going to be tough and
potentially contentious.  HOWEVER, this whole idea could be started with a
single recipe that is commonly installed -- it doesn't have to (and
shouldn't) replace the current flexibility of
researching/downloading/installing the recipes of your choice.

Just my tho'ts -- as usual, Patrick, you've put your finger on perhaps the
most important concerns that need to be considered.  An automatic test suite
is a nice idea and solves some significant problems, but who is going to be
willing to put in the time to develop it.  Choosing just a few recipes
addresses the apples/oranges concern but also limits the value of the whole
bundling idea...  In other words, my answers are valid but perhaps not too
practical...

-Peter

[1] My thought on how an automatic test suite would work would be a series
of pages which get generated into HTML and the resulting HTML is compared
with a known good result from before.  If there is a difference then that
recipe needs to be manually examined to see if the difference is just a
technical change or whether there is a real, practical change which has
occurred, probably necessitating a bug-fix before that recipe could be
released in the new version.  For interactive recipes (i.e., form
processors, etc.) there would probably need to be something that was
processed using iMacros or something like that before the HTML comparison.
There are probably better ways that others could suggest - just my initial
thoughts based off of some of the stuff I've tried to do with WikiSh
testing.




More information about the pmwiki-users mailing list