Session Start: Mon Oct 08 21:58:59 2007 Session Ident: #twiki_release [21:58] * Now talking in #twiki_release [21:58] * Topic is 'http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlockers' [21:58] * Set by CDot on Mon Oct 08 11:19:21 [21:59] hi Kenneth [21:59] Hi Koen [22:00] hi koen, kenneth, (sven?) [22:00] Hi Peter [22:00] * HaraldJoerg has joined #twiki_release [22:00] hi harald [22:00] Ho Peter [22:00] minutes are at http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x10x08 [22:01] i wish i could work outside, such a nice weather [22:01] * ktwilight_ has joined #twiki_release [22:01] 'lo [22:01] I am already on the minutes [22:02] Hello Kwang and Harald [22:02] * ArthurClemens has joined #twiki_release [22:02] Hello Lavr_, ktwilight, Arthur! [22:03] hi kwang & arthur! [22:03] Peter: The weather was fine here as well, but by now it is pitch dark and getting cold [22:04] we are not that many, but we have critical mass [22:04] ah, hi crawford, i did not see you until now [22:05] hi peter. [22:05] * CDot has been here since early this morning ;-) [22:05] hi Lavr [22:05] who is taking minutes, who is facilitating? [22:05] * gmc never left :) [22:05] I am on the minutes [22:05] cool [22:05] on account of doing some $dayjob in the background i'd better not take those roles [22:05] i have a hard stop at +55 min [22:06] i can facilitate unless someone would like to do [22:06] That's fine! [22:06] go ahead please :) [22:06] ok [22:06] propose dagenda items: [22:06] # 1. Review Urgent Bugs [22:06] # 2. Coordinate TWiki Release 4.2 [22:07] anything to add? [22:07] possibly tinymce? [22:07] crawford? [22:08] if not, let's start [22:08] ---+ 1. Review Urgent Bugs [22:08] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlockers [22:08] we have 22 listed [22:08] I just set the first of them http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4782 to "Waiting for Feedback" [22:09] because I can't reproduce it [22:09] let's pick a few we should cover at this meeting [22:09] ...oh sorry... [22:09] I have a short list [22:10] (preparing) [22:10] hmm.. Item4755 -> upgrade issue ? [22:10] i've a comment on Item4570 on DefaultUrlHost. [22:10] ktwilight_: listening [22:10] Item4523, the URLPARAM issue [22:10] i've defaulted mine to 'http://' . $ENV{SERVER_NAME} can we make that as standard? [22:11] so there isn't a need for anyone to actually configure that. [22:11] it would be dependent on the webserver's configuration, which is more reliable? [22:11] lets first finish discussion on http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4755 [22:11] ok [22:12] I have list ready walk though. [22:12] problem: current create topic links will stop working [22:12] ArthurClemens: Could you describe what has *changed* since 4.1.2? [22:12] something I did not oversee when refactoring that topic [22:12] yes [22:12] all inline scripts have been removed from the topic [22:13] the base topic is just a form - to be used by default ski [22:13] skin [22:13] javascript is added by pattern skin view template [22:13] loaded in fact [22:13] (the topic = TWiki.CreateTopic ?) [22:13] yes [22:13] it is a template so skins can override it [22:14] in this case pattern skin adds a js behaviour layer [22:14] this all works fine [22:14] except that that page can no longer be included [22:14] because INCLUDE and VIEW_TEMPLATE do not work together [22:15] alternatives a pretty grim [22:15] are [22:15] . [22:15] 4755 is "only" an annoyance issue that makes upgrading more difficult because you now have to update this one topic in all webs [22:15] * PeterThoeny thinks about potential traffic, needs to leave at +30 min [22:15] Lavr_: which is *VERY* annoying [22:16] * PeterThoeny would like to have someone else facilitate after he leaves [22:16] yes. One work around is to restore the old topic in TWiki web and give the new one a new name [22:16] Can we ship a semi-intelligent perl script in =tools= to be used from the command line? [22:16] restore means: add inline javascript to the topic [22:17] HaraldJoerg: you are hinting to an upgrade script? [22:17] i like the idea of new topic name [22:17] not so easy [22:18] it means that that topic will now rely on behaviour.js [22:18] instead of WebTopicCreator call it WebCreateNewTopic or the like [22:18] (hmm, have to look that up) [22:19] it does mean we will get 2 different topics to create a topic with [22:19] ok, we identified the problem, we do not need to find a solution now, but an owner [22:19] as the "not found" page also uses the new version [22:19] ah [22:19] i'm still trying to grasp the actual problem here.. [22:19] the pages do look quite similar [22:20] actually I would like that I could use INCLUDE + VIEW_TEMPLATE [22:20] If you upgrade from 4.1.X to 4.2.0 this is yet another task you have to do.. copy the WebTopicCreator.txt from one of the new webs to all the old ones. [22:20] so gnc - we are trying to make upgrading less of a pain. [22:20] I cannot even use %INCLUDE{"web.topic?template=blo"}% [22:21] i'm still looking for where in WebLeftBar the create topic is defined, i feel a bit stupid [22:21] enough of this for now [22:21] http://develop.twiki.org/~twiki4/cgi-bin/view/Sandbox/WebHome [22:21] Should I continue with my list of very urgent? [22:22] just below home [22:22] please [22:22] Item2975, Item3367, Item3009, Item3805: all EditTablePlugin items that I chose to change to urgent. We have quite many open items (12) on EditTable and those are the ones that seems to nag more than just one [22:22] Are those old ones or are they related to any changes in 4.2? [22:23] Some are very old. And one is related to the new javascript feature [22:23] where did that developer go? [22:23] Good question. [22:24] Item4244 EditTablePlugin: Very easy to accidently delete row. requires a Javascript guy to fix [22:24] well, it was jointly developed, incl crawford [22:24] now we have two edit table plugins [22:24] I can do the js [22:24] Problem is that we have an insert and a delete button next to each other. You easily hit delete by accident [22:24] it is too late to switch edittableplugin code with edittablerowplugin [22:24] for 4.2 [22:24] What did I develop? [22:25] * CDot tries to remember [22:25] EditTableRow is not a replacement for EditTable. [22:25] no [22:25] not yet because one feature is missing [22:25] no, more than that [22:25] some twiki applications depend on the way edittable works, and that cannot be replaced [22:25] ui is different which can be enhanced [22:26] So Item4244 is for me [22:26] ok, we are diverting, lets look at a merge after the release [22:26] OK thanks Arthur [22:26] back to fixing existing edittableplugin [22:26] thanks arthur [22:27] Item2975: Seems like a regex bug [22:27] or lacking space [22:28] Item3367: A problem with ETP when there is no empty line right after the table. [22:28] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2975 [22:28] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3367 [22:28] with TMCE thing got worse - that is why I elevated it to urgent [22:29] because TMCE in some cases will eat that important empty line after the table if the follow line contains a HTML type tag [22:29] did you test it since I fixed and closed that report? [22:29] No I did not. [22:29] ok. [22:30] I can have a look at this one as well [22:30] cool, thanks arthur! [22:30] Item3009: Looks like another regex bug. [22:30] too bad that code is so ugly [22:31] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3009 [22:31] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3009 [22:31] And finally Item3805: Which is dead annoying when you have an edit table with a footer row with a CALC in the fields. [22:32] THAT simply does not work because of this bug [22:32] on 3009, all twiki code should be done so that separator is comma and optional spaces [22:33] yes. But it does not work as can be seen from my examples. [22:33] meaning a , b is undefined, e.g. a has a trailing space [22:34] regex: /, */ [22:35] I never tested if other comma separated features in TWiki has this problem since I personally always put commas right [22:35] grammatically right [22:36] i believe edittableplugin separator is implemented properly [22:36] so mainly a doc question [22:36] but needs to be verified [22:36] That is OK with me. Take a look at the example I put to verify my observations. [22:36] I will continue with the bugs [22:37] Item4747: One of those TMCE bugs that relates somehow to TMCE eating new lines. <- So I do not see this fixed CDot. [22:37] It is still open [22:37] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4747 [22:37] yep [22:37] So what was it I should check then??? [22:38] For TW's original report there's a simple one-liner [22:38] Lavr_: I didn't say you should check anything [22:38] [22:29] did you test it since I fixed and closed that report? [22:39] the bug report devolved into a discussion; there is no actual report there, except Harald's observation about the whitespace [22:39] Lavr_: that was a different report [22:39] But the question is whether, and how, TMCE has a chance to handle %VAR%[newline]%VAR [22:39] Or rather, TMCE plus HTML2TML [22:40] well, that's a tough one [22:40] No the issue has always been (lately) the tags with lt and gt.
for example. TMCE eats a newline if it is before such a tag. [22:40] Maybe a bad example [22:40] Lavr_: sorry, it's really not that simple. The issue involved in %TABLE was different, and was fixed [22:40] Tags with < > [22:40] this is quite a different situation [22:41] yiu have to think in terms of the boundaries between different types of TML [22:41] between span-structured, and block-structured [22:41] tables are blockstructured [22:41] %VAR% %VAR% is span-structured [22:42] there is no way to say "that newline must be a newline" [22:42] (yet) [22:42] time check: +40 min [22:42] i need to sign off now [22:42] who can take over the facilitation? [22:43] koen? [22:43] I'm afraid I'm not neutral enough with some of the urgent bugs [22:43] for want of a horse, the kingdom was lost. I will do it. [22:43] Peter, sorry i am not focussed enough atm, splitting my attention between 3 things [22:43] CDot: How do you parse the HTML you get from TMCE? [22:44] ok, I have control. Have a safe day, Peter [22:44] ok, thanks all [22:44] i will read the logs [22:44] HaraldJoerg: using HTML::Parser [22:44] bye Peter! [22:44] c-ya Pater [22:44] uh, Peter. my bad. [22:44] np [22:44] cheers [22:44] so I can get the newline, if it exists [22:44] the problem is that different browsers generate different HTML [22:44] IE, for example, throws out *all* linebreaks - sometimes [22:45] No, browsers do not generate HTML at all. [22:45] Yep. IE and FF differ exactly on the newlines. Terrible [22:45] HaraldJoerg: ? [22:45] So that's an issue betweenn TMCE and the browsers? [22:45] the HTML is nothing to do with TMCE [22:45] it is generated from the DOM, by the browser [22:46] Ouch [22:46] TMCE uses MIDAS [22:46] I didn't know it was that bad [22:46] hell, that's the tip of the iceberg [22:46] hm, maybe using WYSIWYG is a bit too early? [22:46] there are at least four workarounds for FF bugs already coded in :-( [22:46] ktwilight_: the right time will never come.. [22:47] possible [22:47] I think we all understand the basic problem. [22:47] shall I continue? [22:47] please [22:47] Item4771: Seems close to resolution. Very good work of Sven. Harald you agree? [22:47] (SSO bug) [22:48] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4771 [22:48] What is important for me is that I do not loose the ability to be authenticated and allowed to edit - but not registered. [22:49] Anything you lack now Harald? [22:49] I don't - but I thought you were concerned about unregistered users indistinguishable from guest? [22:49] No. I know the difference. The REAL guests are the ones that cannot authenticate. [22:50] And I simply block those with DENYWEBVIEV in all webs [22:50] Works great [22:50] Maybe it's about time to document some sort of "best practice settings in a corporate environment"? [22:50] The minute a guest arrives he is forced to authenticate. If he cannot. Good bye. [22:51] Yes. Harald. That would be a good idea. On Codev supplental docs [22:51] Eh. Twiki web on t.o [22:51] I was surprised that our setups are so similar [22:51] I wish we had a better place for FAQs like that [22:51] so can we close 4771? [22:52] Waiting for Release, yes. [22:52] If Harald is happy then I believe it can be closed. [22:52] 8-) [22:52] next? [22:52] Item4707: I have a proposal which I would like Carlo and Arthur and anyone else with an interest to comment. [22:52] can you summarise quickly? [22:52] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4707 [22:53] I am not keen to do any more work on this [22:53] I propose to add an extra menu entry in --Styles-- in TMCE. Just below --Styles-- [22:53] not easy. Not at all easy. [22:53] Which does exactly the same as "--Styles--" but is called "No style" or "None" or similar. [22:53] I looked at doing that, and it would be a lot of work, requiring a new plugin [22:54] Lavr_: you _can_ use the eraser icon [22:54] You cannot just add an extra menu below called "None" and do the same as the one above? [22:54] no [22:54] No Arthur. You cannot [22:54] the styling disappears... [22:54] The --Styles-- item works. It is just not obvious that it removes a style [22:54] or seems to [22:55] the --Styles-- entry is *not* a menu item; it is the menu title [22:55] it is not accessible for configuration [22:55] The --Styles-- entry works though. It removes the 3 possible styles. [22:55] I tried to rename it - to "No Style" - but even that was beyond my abilities. [22:56] it does not with me [22:56] only the eraser works [22:56] What style are you erasing? [22:57] the styles [22:57] verbatim, literal and so on [22:57] Lavr_: do you consider the current situation to still be release-blocking? [22:57] No. But I assumed it would be an easy one that just required agreement [22:57] no, afraid not [22:58] can we downgrade it to "Normal but a real PITA that needs to be fixed" status? [22:58] Yes OK. [22:58] really, the same on Windows IE [22:58] ok. Next? [22:58] it would be great to have the styles marked with color [22:58] The worse and last. [22:58] Item4737: This we MUST find a work around for. People will loose work on that. I have added a proposal. [22:59] My proposal is to: Do the mandatory check in javascript so you simple cannot save. And remove preview. [22:59] from TMCE. [22:59] that makes sense [23:00] arthur, is there a special class for mandatory form items? [23:00] I don't think so [23:00] would it be hard to add one? [23:00] Lavr_: there might be other things that has the user hit 'back' [23:00] yes, just typing in the URL bar would do it [23:00] although the mandatory fields one is the most obvious one [23:01] Yes. But then it is more acceptable to "loose" data. [23:01] but there might be other problems that prompt the user to hit back [23:01] argh, no, blocking the navigate-away would be far more irritating [23:01] I *hate* sites that do that [23:01] When you force the user because he forgot a mandatory field but typed for 30 mins in other fields then we MUST protect him from himself [23:01] must..not..force..user.. [23:02] but if they confirm.... then we must do as they say [23:02] * PeterThoeny has quit IRC (Connection timed out) [23:02] even if they lose daya [23:02] It is the mandarity field usecase AND the preview where we lure the user to press back as part of normal UI. [23:02] it would be better if the preview was on the same page, in an iframe [23:03] Preview is not needed with Wysiwyg - most never preview anyway. [23:03] erm, how about a launchWindow for the preview? [23:03] my preview: safe, and if it doesn't look nice, hit back [23:03] anyway, the same is true for a normal save [23:03] if a mandatory field is empty [23:03] gmc: You're doomed if your topic was an XXXXXXXXXX one [23:04] I still prefer the same page over a pop-up [23:04] HaraldJoerg: i'm doomed anyway :) [23:04] because every save will create a new topic [23:04] erm, we could have a message box "Install Opera now" [23:04] HaraldJoerg: i actually do have some intelligence somewhere that prevents me from 'Back'ing on AUTOINC topics :) [23:04] Lucky you :-) [23:04] i'm actually tempted to solve the bug in firefox.. [23:05] tempted.. but i know nothing of ff codebase, so that's not much of an option [23:05] gmc: it's been open since 2002 [23:05] which suggests it's non-trivial [23:05] so basically, we have had this same problem with kupu too? [23:05] yes [23:05] with *any* editor that replaces textareas [23:05] strange though, that no-one complained [23:05] wikiwyg, dojo, all of them [23:05] there are many complaints [23:06] I've always thought of preview as a candidate for AJAX [23:06] Drupal coded around it [23:06] yeah, i saw it.. [23:06] so that the "view" could come into some DIV element on request [23:06] maybe we have to code around it too.. [23:07] I think we should [23:07] and a mandatory check in JS is one way [23:07] ajax is no problem, but we don't have it installed be default [23:07] storing the field values somehow, and retrieving them is another [23:07] yes [23:07] perhaps via a clever REST handler [23:07] god forbid [23:07] * CDot doesn;t feel that clever [23:08] a cookie is the conventional way, but we have far too much data [23:08] reordering the form fields is the simplest solution [23:08] reordering as in putting form first then textarea? [23:08] y [23:09] we can place them the normal way with js [23:09] hmmm, and then swap them with some js [23:09] brr [23:09] without moving them in the DOM? [23:09] hmm [23:09] it's their position in the DOM that's critical [23:10] so when does ff fill in the values.. after your page is completely rendered, including any onloads ? [23:10] so our tabbed interface is coming near [23:10] as I understand it, when you go "back" in FF it fills in the values in the DOM *before* onload is called [23:11] oops, I meant *after* [23:11] oh darn [23:11] you gave me some hope there [23:11] that's the bug [23:11] anyway, we can;t solve it here [23:11] I don;t have a solution, and TBH I'm out of ideas [23:11] I like the js validation [23:11] and motivation to fix it, frankly [23:11] i don't like the js validation [23:12] why not? [23:12] i would prefer the solution with a cookie linked to storage via some REST handler or the other [23:12] why not? [23:12] we are not going to solve it here [23:12] ArthurClemens: it's a less general solution imho [23:12] I think the usability of disabling the save if mandatory fields are missing is much better. So not only is it a work around. it is an improvement [23:12] let's move this discussion into the topic, please, and move on [23:13] ok [23:13] we can come back if we have time [23:13] do we need to talk about the URLPARAM thing some more? [23:13] next? [23:13] I have mentioned the ones I wanted to discuss today. [23:13] ok, then the URLPARAM thing [23:13] Item4523 [23:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4523 [23:13] I provided the SafeWikiPlugin, and Arthur has been moving scripts out of line [23:14] I think we are in pretty good shape [23:14] we are.. [23:14] but no testing feedback :-( [23:14] I still have some templates to look after [23:14] not a word [23:14] is SafeWikiPlugin going to be enabled by default? [23:14] Will the default plugins work with SWP? [23:14] it isn;t at the moment [23:14] Lavr_: good question, only ansered by testing [23:14] Like EditTablePlugin which is now full of js? [23:14] CDot: i can give you plenty of feedback, a month from now... :( [23:15] some may not - I have doubts about EditTablePlugin [23:15] I know ATP has issues [23:15] but that isn;t default. [23:15] if it's any consolation, EditRowPlugin works fine with it [23:15] I do not think that SWP will be ready for the release. BUT the fact that we have prepared for the plugin is enough to show the customers that we care and there is more to come [23:15] so there is always a fallback [23:15] I can't test SafeWikiPlugin in "real life" because we have a lot of inline scripts [23:16] triggered by preference variables [23:16] " I do not think that SWP will be ready for the release" - why not? [23:16] HaraldJoerg: i can tell you the test results already [23:16] EditTablePlugin even has a handler 'dynamicJavascriptForTable' [23:16] test time CDot. test with the many plugins. [23:16] oh, for enabling by default. Yes, I agree [23:16] I am more concerned that we have a solution available [23:17] even *with* broken plugins [23:17] But the development of the plugin can continue with many release after we release twiki itself. [23:17] As long as TWiki itself is working with it [23:17] there is no more development needed on the plugin [23:17] it is *other* plugins that are the problem [23:17] we need a SafeWiki badge [23:17] for plugins [23:17] good idea! [23:18] I did a lovely logo [23:18] * ArthurClemens hides [23:18] :-D [23:18] CDot: does it involve condoms? [23:18] gmc: the first one did [23:18] :-)) [23:18] but then I thought that wouldn;t go down well [23:19] I have a question about "remember me" [23:19] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4523 [23:19]