> > [...] > > 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. _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
