[pmwiki-users] Pre-announcing 2.2.0 non-beta release, new release manager
editor at fast.st
Tue Jan 20 09:42:34 CST 2009
On Tue, Jan 20, 2009 at 10:09 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, Jan 20, 2009 at 03:35:49PM +0100, Peter Bowers wrote:
>> > > one thing is probably very important: have some way to install major
>> > > cookbooks from a drop down list or checkbox
>> > This isn't likely to happen (the drop-down list or checkbox part),
>> > because we don't want the webserver to have write permission to
>> > the cookbook/ directory.
>> I think the origin of the "automatically installed cookbooks" idea was much
>> more similar to what you find in scripts/authuser.php.
> We probably need a phrase other than "automatically installed cookbooks"
> then. Possibly "pre-installed recipes" or "pre-bundled recipes"
> or something like that. There are, of course, some questions:
>> This is a "recipe"
>> in a sense but it was approved as something that gets installed in the
>> scripts/ directory instead of the cookbook/ directory but only gets turned
>> on by an intentional editing of the config.php file.
> It actually goes beyond this -- authuser.php is not only "approved",
> there's also a promise that in each release it's reviewed for
> correct functionality and that subsequent releases will continue
> to support that functionality. It's not as if we simply took a
> recipe and decided to bundle it in the core distribution -- there's
> also a promise of ongoing maintenance for the future.
>> My understanding of
>> the "some way to install major cookbooks" idea is that these recipes would
>> be installed by default when you unzipped pmwiki.zip (or whatever). Then
>> the difference between activating a script by editing config.php and
>> activating it by editing a wiki page (or checking a box on a form in an
>> admin page which simply updates PTVs on that page, for instance) is trivial.
>> 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. :-)
> 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?
> 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?
> 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?
> 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.
There is another option. To use the example of BoltWire again---no
plugins are currently installed with the core distribution. Just a
folder where plugins can be dropped. So no endorsement is made of any
plugin, no selection criteria concerns, no worry about upgrades, none
of those questions. Everything is left to the admin and the recipe
developer, just as currently in PmWiki.
The site.config page just enables you to take any recipe in your
cookbook folder (list generated dynamically via a pagelist) and turn
it on from within the wiki. In fact, there's a simple install action
that makes it as easy as selecting a plugin and clicking a button.
Agreed it lacks some of the options available when doing it as a
config file, but those can still be used where needed. And for a new
user, it makes installation very nice.
Pm's idea of putting all config variables in an array is also done by
BoltWire so you have a much easier time setting config variables in a
wiki page, but I'm sure there could be work arounds in PmWiki without
major disruptions. Another option to consider, is some kind of backup
system for wiki pages used by a plugin that gets installed
simultaneously when the corresponding php file is enabled. This gives
a really nice wow effect when one just clicks a single button and
boom--instant working shopping cart or forum or instant messaging
More information about the pmwiki-users