Session Start: Mon Jan 08 22:07:47 2007 Session Ident: #twiki_edinburgh [22:07] * Now talking in #twiki_edinburgh [22:07] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2007x01x08' [22:07] * Set by SvenDowideit on Mon Jan 08 15:04:18 [22:08] Good evening. Sorry I am late. [22:09] hi Lavr [22:09] hi kenneth [22:09] * StephaneLenclud has joined #twiki_edinburgh [22:09] hi stephane, nice to see you here! [22:09] * HaraldJoerg has joined #twiki_edinburgh [22:09] hi harald [22:10] Hi [22:10] Sorry for being late [22:10] i think we are ready to go [22:10] Yeah I was passing by I thought I'll watch :) [22:10] you are welcome to watch, and also welcome to voice! [22:11] as usual lavr/pth? [22:11] I am on the minutes already [22:11] ok, i will facilitate [22:11] agenda items: [22:11] # [22:11] # 1. Review Previous Action Items [22:11] # 2. Review Bug Fix Status of TWiki 4.1 [22:11] # 3. TWiki 4.1 Release Coordination [22:12] anything to add? [22:12] nope [22:12] if not, lets start [22:12] ---+ 1. Review Previous Action Items [22:12] * Skin experts. Give Thomas final feedback on TemplatePathBuginTWiki4x00 so he can finish the docs [22:12] any update? [22:13] Sven is active at this atm it seems [22:13] this item is not so SMART [22:14] who is supposed to give thomas feedback? [22:14] the only feed back i can give [22:14] is I don't understand what has been written [22:14] this is feeback too, at least this gives thomas the chance to follow-up [22:14] No we had the impression last time that we had done what could be done atm. [22:14] there is not enough summary, nor anything to give those tha tdon't already grok the code a feel for what happens [22:15] is this the one where it is only doc update in the code? [22:15] not sure really :( [22:15] I think it's user doc [22:15] TWiki.TWikiTemplates repeats the list [22:15] right [22:15] but its a very tech like info [22:16] and so hard to grasp things like 'why the hell is it so damned complicated' [22:16] how important is it for 4.1? [22:16] (i mean the docs) [22:16] if not urgent i suggest to drop it from the action items [22:16] thats a much harder q :) [22:17] i'd drop it too, as what is doccoed, is better than before [22:17] sven: could you add a note asking for clarification? [22:17] the massive thing missing, is a set of actual real tests [22:17] i think i have [22:17] and nothing was changed [22:18] I think we have what we need for 4.1. Thomas is probably about 3 times as advanced as any other advanced user and has quite different needs. [22:18] as 'clarification' is also not SMART :( [22:18] ok, no action unless initiator acts [22:18] # Peter: Skin/Javascripts changed so initial letter for renaming and creation changes first letter to uppercase. Classic skin missing [22:18] this item is pending [22:19] what does 'Classic skin missing' mean? [22:19] javascript changes for classicskins are missing [22:19] # Bugs:Item3261 Literal search on all webs does not work. Peter will try and fix [22:20] this is done, except for docs [22:20] classic skin uses JS? [22:20] yes, with graceful fallback [22:21] # Bugs:Item3370 Release note for 4.1: Kenneth finishes the release note; Peter adds a contribution list on TWikiHistory and updates AUTHORS file [22:21] pending action item for me [22:21] SvenDowideit: http://develop.twiki.org/~twiki4/cgi-bin/view/Main/WebTopicCreator?skin=classic [22:21] Yes. My update is on the day of release. [22:21] # Bugs:Item3371 Walkthrough of all default plugins to ensure latest version of default plugins are on TWiki.org. Kenneth will start this [22:22] SteffenPoulsen, ah, ta :) [22:22] But it does make the start letter upper case! [22:22] item 3371 can be done shortly before or after release [22:22] # Bugs:Item3378 default templates cause invalid HTML [22:22] what is the status on this one? [22:23] thats done [22:23] TWikiHistory is in the distro [22:23] except the base thing i made a new bug for [22:23] The base thing. I added a note [22:23] Sven: That's not a bug, that's XHTML. [22:23] What is the new bug? [22:23] it fails validation [22:23] but worse [22:23] base url is set to view [22:23] Then the validation code is bogus. [22:23] even on edit [22:23] sven: yesterday i noticed that classic print skin has two copyrights at the bottom [22:24] and so its a bug.. [22:24] Arthur added it to avoid an IE bug. [22:24] PeterThoeny, ta :) [22:24] print hurts [22:24] PeterThoeny, http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3403 [22:25] ok [22:25] ok, sven is on top of 3378 [22:25] # Bugs:Item3399 Template system recursion prevention too agressive, prevents skin specialisation, or mixins [22:26] what is the status on this one? [22:26] i see the notes by tw and sd [22:26] I connited a fix, and test cases today [22:27] TW seems under the impression its new functionality [22:27] but its actually something i used pre twiki4, and was made to work again in 4.0.3 [22:27] looking at the code history, i think thomas mis read the old code [22:28] as $name used to be filename, now its the bit before the SKIN.tmpl portion [22:28] if Set SKIN = foobar,pattern fails to work then it needs to be fixed [22:28] basically :) [22:28] so it is an urgent, as stated [22:28] and this time i made a few tests and added docco to TWikiSkins and TWikiTemplates [22:29] are yousven and tw on top of it? [22:29] But it is waiting for release and DONE right? So only action is to explain to good old TW [22:29] i'm on top of it, in that its finished [22:29] correct :) [22:30] ok, nice [22:30] # Bugs:Item3401 base tag refers to topic view, irrespective of what the current base url actually is [22:31] sven, what is the broblem with ? [22:31] if you hit edit on that topic [22:31] you will see that base is set to the view URL :( [22:31] Ah. Now I understand. The VIEW instead of EDIT. [22:32] my issue with is more due to the fact it gets added to the default skin, even though i might not want it to [22:32] ok, the /view/ is the issue [22:32] as in, its done by code [22:32] but the URL is the real issue :) [22:32] the base is added for a reason [22:32] as it breaks my majicks [22:33] y, but i'd rather add it in my skin [22:33] you can have urls without topic name and also without web name [22:33] without the base you would point to the wrong place [22:33] y, i grok [22:33] for 4.1: we can't change the spec, but we need to fix the /view/ issue [22:34] yep [22:34] i hope its a simple one for the author of that code [22:34] who is on top if the fix? [22:34] s/if/of/ [22:34] i'll only have time to look at it if my real work is done :/ [22:35] and i have a few thosand lines of JS to write yet [22:35] this is a relaase blocker [22:35] ok [22:35] # DropClassicSkin is unloved [22:35] what is unloved, the dropping or the skin? [22:35] As Sven had noticed I did suggest to bring it up here. [22:36] i agree that its too close to 4.1 really - but was toungue in cheek replying to Lavr's suggestion :) [22:36] actually, this is not an action item from the previous meeting [22:36] Not to discuss dropping. I suggested to discuss if we should add a deprecation warning in release note. [22:36] but lets discuss this now [22:36] but I could... make a modification of it [22:37] classic skin could be re-done derived off the new default [22:37] just today we had some good suggestion in that topic [22:37] which might result in under 100 lines of tmpl [22:37] or much less actually.. [22:37] When I suggested it I had no idea some fans of Classic would show up and defends its existance. [22:37] simplyfy the default templates and keep classic skin as a demo of how it can be done in a few lines [22:37] when you use the template_cache code i wrote [22:38] and then diff the outputs of classic and default, there are very few [22:38] PeterThoeny, y [22:38] then there would be 2 very different foccussed examples [22:38] turning it into a demo with a few well-chosen and explained overrides would be great I think [22:38] one for pure CSS, and one for non-CSS [22:39] ok, shall we toss that action as a I'll work on it, and _if_ its ready in time, we'll run with it? [22:39] I now have a toolset that compares the template processing [22:39] ok, so, do i read that the classicskin is not deprecated because it is a good demo on how to skin the cat? [22:39] If the default will look at Classic anyway I see no reason to make a deprecation warning. [22:39] We should keep CLassic skin *of* it is maintained and *if* it is a good example of how to write a skin [22:40] ^of^if [22:40] so i may be able to show that the mini-classic has an identical output to twiki4-classic [22:40] past history suggests it is not maintained [22:40] and it is very complicated and difficult to extend/derive from [22:40] yep [22:41] organic growth, yes, it was well designed in the beginning [22:41] for sure; but it grew warts [22:41] lots of them [22:41] personally I would vote to ditch Pattern as well, if there was a viable alternative [22:41] grin [22:42] for the same reasons [22:42] I recon a zengarden pattern would be trivial [22:42] for a css preson [22:42] no, pattern is very good from usability, the underlying code can be simplified [22:42] i will write a codev topic on it [22:42] I like pattern usability [22:42] I'm not criticising usability. Classic is quite usable as well. It's the underlying structure... [22:43] I'll attach a diff to a bug wrt making classic derived from default [22:43] remember that we expect people to build their own skin on top [22:43] and if its up to scratch, we cna decide quickly to take / wait [22:43] ok, back to topic: deprecate classiciskin or not in 4.1, that is the question [22:43] I thought pattern was fully redesigned soon after 4.0.0 [22:43] I say "deprecate, remove in 4.2" unless a maintainer steps up [22:44] na, if classic derived from default is not out for 4.1, it will be in 4.1.1 / 4.1.2 [22:44] Stephane: There were important *fixes* in 4.0.2, but no redesign [22:44] i say, keep to demo ease of skinning [22:44] no need to deprecate [22:44] So the thing to decide is. Do we put a deprecation warning in release note or not? [22:44] sven is on top of the base template redesign [22:44] i vote no :) cos i'd like as many 'customers' of my default work :) [22:44] hang on a mo; why do we need a warning? [22:45] we are not talking about deleting it [22:45] so classicskin is a good demo, especiaqlly if it can be done in a few lines [22:45] just remobing it from MANIFEST [22:45] If we remove it from default zip it is DEAD. [22:45] not if it is maintained [22:45] OK, can I propose: [22:45] same as any other skin [22:45] Hardly anyone maintains it now. It is touched now and then out of pure duty because it is in default set. [22:46] since classic ~= default I think we can safely remove it without warning people using won't even notice that they are actually using the default instead of classic [22:46] If it goes in plugin land it is doomed. [22:46] the key issue is that the default template and the classicskin are two separate things, confusing to keep both updated [22:46] it should become a couple of files, with a few lines in it [22:46] If the default no skin eventually will look like Classic then there is nothing to deprecatein practical. [22:47] if the classicskin can be derived in a few lines from the the default templates as sven suggests we are in buysiness [22:47] either to go into 4.1.0 or 4.1.1 depending on progress in the next days.. [22:47] for sure [22:47] I hope that we can make a demo case out of Classic, too early for a deprecation/removal for my taste [22:47] I know it can be done, its a question of if i have time before the release [22:47] I'd be happy to have lots of skins in the default package, but *only* if they are maintained/maintainable [22:47] but I will have time in Feb [22:47] We have ONE week to release. [22:47] and then I will look at pattern too [22:48] y, so i propse ;do nothing, unless my mini classic works' [22:48] ok, how about this: [22:48] 1. no deprecation [22:48] 2. keep default templates and classicskin out of sync for 4.1 [22:48] 3. derive classicskin from default templates in a patch release [22:48] where 'works' == template_cache shows no real change from twiki4 [22:48] fine by me. [22:49] this is the least amount if work and impact for the 4.1 release [22:49] that works well for me [22:49] arthur sounded happy for me to do the same to patter (assuming it works) [22:49] Me too [22:49] ok [22:49] ---+ 2. Review Bug Fix Status of TWiki 4.1 [22:49] well, we are already into it :-) [22:50] # Bugs:Item3393 sounds like it might be a potential security hole [22:50] I could not reproduce it. [22:50] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3404 - classic skin item [22:50] i am not sure how the edittableplugin could do something special in regards to access control [22:51] possibly a missing viewauth? [22:51] I am sure it is a configuration issue. [22:51] or viewauth not under auth [22:51] can't reproduce either [22:51] ok, not a release blocker then [22:52] Seems like a discard. [22:52] no, lets give the reported a chance for feedback [22:52] "reporter" [22:52] Yes. Agree. But we treat it as if it was release-wise. [22:52] lets review the "Items by urgency" [22:53] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/AllOutStandingItems?class=Engine%7CDocumentation&=&sortcol=3;table=1;up=1#sorted_table [22:53] on release blockers, we talked about a few [22:53] lets see what is left... [22:54] I wasn't sure how editPlugin handled saves [22:54] whether it went through access control or not... [22:54] I'm pretty sure the reporter hasn;t configured require valid-user correctly. [22:54] all action is done by viewauth script, e.g. it does so if viewauth is under auth [22:55] but what about CHANGE on the save? [22:55] save action is done by viewauth script, triggered by url params [22:55] most likely issue is that viewauth is not under auth [22:55] agreed [22:56] next: [22:56] # Item3394 Remove UpgradeTwiki script, or put prominent warning on issues [22:56] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3394 [22:56] ok. Well, I will check to satisfy myself it is secure. [22:56] remove upgradetwiki or mark as dangerous? [22:56] I think it the upgrade script should be removed. We have had many support issues with people that used it. [22:56] CDot: Thanks [22:57] thanks crawford [22:57] I'm happy to have it removed, as no-ones taken it up [22:57] I agree with Lavr. His recipe is much better [22:57] i agree, we help users and us in support if we remove the script [22:57] who takes the a.i. [22:57] ? [22:57] I can take that action. [22:57] we tried, but TWiki's fundamentally not magically upgradeable [22:57] thanks kenneth! [22:58] agreed to remove it, possibly deprecate and let it print TWiki.org upgrade guide url [22:58] grin [22:58] basically remove from manifest and update the upgrade docs [22:58] mmm, there are libs too, [22:59] i think that;'s it for release blocker items [22:59] Yes. That is the action. [22:59] Libs?? [22:59] Libs containing Upgrade code [22:59] lib/twiki/upgrade or something [22:59] we did alot of work [22:59] I will check. [22:59] do not remove from svn, someone will pick it up later [22:59] I'd say they won't harm even if they are in the distribution [23:00] its a non-trivial body of work, which is pretty much the fatal flaw [23:00] +60 min [23:00] lets scan over the "survivable bugs and irritations" list [23:00] anything that should be highlighted? [23:01] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3402 [23:01] might be useful [23:01] i didn't realise there was that limitation [23:03] evil [23:03] any idea why it happens? [23:03] Did anyone reproduce it? [23:03] no, i just reported it for now [23:03] as it was put in by a debian user into the debian bug system [23:03] it's not a blocker, though a doc would be nice [23:03] is this a release blocker? [23:04] not as far as i know [23:04] we moved on :) [23:05] it is a nice to have fix [23:06] any other items that are worth mentioning here? [23:06] how are we with translations? [23:06] translations look good I think [23:06] Do you agree to postpone 3105 (misleading "invalid activation code") to 4.1.1 to allow for simultaneous I18N? [23:06] forign! [23:07] OK, i just confirmed that EditTablePlugin can be used to modify a topic that has ALLOWTOPICCHANGE = set to disallow changes. [23:07] http://twiki.org/cgi-bin/view/Codev/UserInterfaceLocalisation#Current_translation_status [23:07] http://twiki.org/cgi-bin/view/Codev/TWikiTranslationStatus shows that cs, es, ru are not complete [23:08] they can be made up-to-date at a later state and downloaded for installations needing them [23:08] oh [23:08] what happened to FuncContrib etc [23:08] so, incomplete translations are not release blockers? [23:09] not in my view, but there is no documented proces for this [23:09] the missing ones are 80% to 90% complete [23:09] i am fine with that [23:09] FuncContrib and MoreFuncContrib were intended to go into the next major release's TWiki::Func [23:10] how complete is it? [23:10] (funccontrib) [23:10] is it actively maintained? [23:10] as activly as Func [23:10] they were intended as staging areas for moving into Func [23:11] we need to be careful with adding stuff one week before release [23:11] so that Func does not stand still [23:11] i'd say the train already left the station [23:11] but y, if you're not aware, thats enough to leave it [23:11] SvenDowideit: and FuncUsersContrib. I realised this a couple of weeks ago, and realised it was too late at the same time. [23:11] y :( [23:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2354 [23:11] can we make this for 4.1.1? [23:12] ah, that is the stuff from ml [23:12] no [23:12] do we have an owner now? [23:12] its the stuff from ml, me & cc [23:13] quite a few of the plugins i've written use them [23:13] lots of good stuff. But too late :-( [23:13] the plugins can still use the contribs. [23:13] ok, for a later discussion [23:13] PeterThoeny, take a look some time, but we all vote for post 4.1.0 [23:13] We can add in release note that they get added in 4.1.1. Then at least plugin writers know they can use them. [23:14] sold, to the release manager man over there :) [23:14] any other bugs items to discuss? [23:14] sounds fair :-) [23:14] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3092 [23:14] for my taste we still have way too many bugs open [23:14] I believe this EditTablePlugin bug is a blocker [23:14] a user contrib tahts not horrid.. [23:15] just mailing twiki-security with details [23:16] If word is free I am experiencing a problem with http://develop.twiki.org/~twiki4/cgi-bin/view/TWiki/ResetPassword - it only works if I am logged in, and my installations work the same way - but apparently this is a configuration issue (http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3400). [23:16] oh, thanks crawford [23:16] thanks cc [23:17] if noone else experiences this, no need to let it block [23:17] 3092: ok with me, if done, do it also for webatom [23:17] cool, i'll tickle it [23:18] any feedback for steffen on 3400? [23:18] I tried on my merlin.lavrsen.dk and I can reset password without being authenticated. [23:18] Also with template login! [23:19] The typical config error is to authenticate all files in bin. [23:19] resetpasswd must not be Apache authenticated! [23:20] ok, lets move on [23:20] ---+ 3. TWiki 4.1 Release Coordination [23:20] http://twiki.org/cgi-bin/view/Codev/ProductionReleaseChecklist [23:20] i am on top of pr [23:20] mmm [23:20] I did not make an RC3 yesterday because there was some new open bugs that looked important. But I can make one tomorrow. [23:20] does WebAtom work ATM? [23:20] IF needed. [23:21] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/WebAtom [23:21] i asked google for a testimonial for the press release, the open source representative was supportive, but unfortunately a negative reply by the pr dep [23:21] PeterThoeny: damn [23:21] would have been great :-) [23:21] yes [23:22] back to more e-mails [23:22] Good try [23:22] Would have been nice indeed [23:22] SvenDowideit: Doesn't look to good according to w3c (http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fdevelop.twiki.org%2F%7Etwiki4%2Fcgi-bin%2Fview%2FBugs%2FWebAtom) [23:22] i got someone else helping me on the pr side [23:23] y, added note to http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3092 [23:23] kenneth and i will handle the twiki.org topic updates [23:24] decide on codename: http://twiki.org/cgi-bin/view/Codev/CodeName [23:24] any more votes? [23:24] I'll be away, with no computer from friday, so i'm under crunch - need to orgainse moving back to sydney, a 3 week holiday and more [23:24] I like Fun-i-futi [23:24] Freetown +1 [23:24] the please vote on the topic [23:24] done [23:25] I'm withdrawing the comment on ETP exploit; I realised I had disabled access control checks for another bug. My bad! [23:25] YAY :) [23:25] ok, good to know crawford [23:25] That is good news CC [23:26] CDot: keeping yourself busy? :-) [23:26] shall we go for democratic vote, or discussion until agreed for the codename? [23:27] I think Sven was making a bit of fun (Capital of Laughter-i-place?), so no conflicting voices [23:27] we have now 7 freetown and 2 funafuti [23:27] Don't mind. Should be release manager's decision. [23:27] ah, sorry [23:27] BTW who *is* release manager for Funafuti/Freetown? [23:27] Democratatorship is probably best way. [23:28] Sorry, I have to leave for today. [23:28] i vote for kenneth, he is doing a marvelous job [23:28] see you around, Harald, thanks for joining in [23:28] (if lavr agrees) [23:28] Bye Harald. And thanks Peter. [23:28] thanks harald [23:29] And I'll be very silent for the next six weeks, my spare time is being used by helping to organize http://www.perl-workshop.de/en/2007/index.html [23:29] i'm a little distressed about using Lavr [23:29] So, see you later :-) [23:29] ooo, laters HaraldJoerg [23:29] good luck harald! [23:29] * HaraldJoerg has left #twiki_edinburgh [23:29]