Session Start: Mon Dec 17 22:02:17 2007 Session Ident: #twiki_release [22:02] * Now talking in #twiki_release [22:02] * Topic is 'http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlockers' [22:02] * Set by CDot on Mon Oct 08 10:19:21 [22:02] and it is synchrnised with the atomic clock in Lancaster [22:02] so, either it's 21.02, or someone has changed the oscillation frequency of Caesium 236 (again) [22:03] hi arthur, crawford, koen, kenneth, oliver! [22:03] hey Peter [22:03] youth nowadays! [22:03] Hi guys [22:03] * PeterThoeny wonders what the wikiringbot is [22:03] hey [22:03] yes, my desktop was right too... turned out the server my irc client runs on wasn't synced to ntp [22:03] PeterThoeny: same as it always is; a logbot [22:04] ntp everywhere! [22:04] i know harlan stenn, the key contributor of the ntp project [22:04] i'm running an ntp pool node too :) [22:05] proposed agenda is at http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x12x17 [22:05] we have critical mass, we can start [22:06] who is taking minutes, who is facilitating? [22:06] I am already on the minutes [22:06] proposed agenda: [22:06] # 1. Review Urgent Bugs [22:06] # 2. Coordinate TWiki Release 4.2 [22:06] i can facilitate [22:06] anything to add to the agenda? [22:06] Not from me [22:06] no [22:07] go ahead [22:07] ---++ 1. Review Urgent Bugs [22:08] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker [22:08] We have 4 to discuss [22:08] hmm, why is this page so short, it used to have several sections [22:08] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5141 Wysiwyg will happily save 'Please wait... retrieving page from server' as topic text [22:09] PeterThoeny: it has only ever had one section (you are thinking of AllOutStandingItems) [22:09] ok, so i freshly added 5141 just now.. [22:09] Lavr_: that was reported in the last few minutes, so has not been analysed yet [22:10] we had that bug a couple of weeks ago [22:10] and was fixed 6 days ago [22:10] we did? [22:10] does it still happen? [22:10] maybe.... depends on how gmc created it [22:10] might be a different bug [22:10] ok i had it happen on develop.twiki.org just 30 minutes ago [22:10] All day today Bugs have been hanging saying "Please wait... retrieving page from server" for me while connecting from work. Maybe a bugs/Fastservers issue again [22:10] Lavr_: me2 [22:10] * HaraldJoerg has joined #twiki_release [22:11] but if you don't pay attention, modify some form fields, and hit save, it even ends up as the topic text, wiping what was there.. [22:11] I have not observed same behavior on my own 3 test servers. 2 at home and 1 at work [22:11] can be retrieved of course from earlier history, but still pretty annoying [22:11] actually I have the hanging bug too because of a js error [22:11] save is disabled (in JS) until the topic text is loaded [22:11] or at least it should be [22:11] hmmm, so maybe tha tis not merged to main yet? d.t.o is main, right? [22:12] please describe how to reproduce the problem [22:12] twiki_tiny.js: onFail is not defined [22:12] No - I have saved two new bugs today. I let it hang. Wrote the new bug and saved. [22:12] I'm pretty sure I merged it [22:12] * CDot checks [22:12] so it is a new js error [22:12] hi harald, thanks for joining! [22:12] reproduce: hit 'edit' on a bug and hit save before the topic is loaded..... [22:13] gmc: can you reproduce it on 420? [22:13] CDot: dunno, i don't have it running on any slow servers :) [22:13] ok, i just messed up the bug report :) [22:13] nice one! [22:14] I just tried it on 420 with a delay loop [22:14] and it worked as expected (save is disabled) [22:14] so this needs verification, but I don;t think it's a release blocker [22:14] Ah - you're talking about TWiki hanging while showing "please wait". I've seen that [22:15] 4.3 gives the js error [22:15] ok, this is odd, i can't retrieve the original text anymore either [22:15] function onFail is not defined [22:15] Harald: You have seen it on other servers than Bugs? [22:15] http://develop.twiki.org/~twiki4/cgi-bin/edit/Sandbox/CommentPluginExampleComments?t=1197926074 [22:15] ArthurClemens: browser? [22:15] firefox [22:15] ok, I see no error on FF with 420 [22:16] it is on 4.3 [22:16] MAIN [22:16] Not yet. On dto, I [22:16] Not yet. On dto, it is accompanied by a 500 status code when trying to retrieve the text for TMCE [22:16] the error console highlights onFail, and a text search does not find this function [22:16] ah yes, 'onFail is not defined' i see that too [22:16] twiki_tiny.js, line 7 [22:17] i just filed a new bug entry and got this message in red letters too [22:17] so actually, these are two bugs then: 1. where it is not loading the topic text, 2. where it is saving when the text is not loaded yet.. [22:17] and both are not in 4.2, but in main.. apparently... [22:18] Guess CDot needs to check the two repositories then. [22:18] Seems like a plain merge error [22:18] strange though, how all revisions show that text now on the bug report :( [22:18] the repositories are identical, as far as I can tell [22:19] i wonder where my original text went... [22:19] time check: +20min [22:19] * PeterThoeny has a hard stop at +60 min) [22:19] Maybe Bugs is not SVN updated correctly. [22:19] so usually onFail is not called [22:19] so does not give this error [22:19] perhaps [22:21] ok, we identified the problem, who is looking into it? [22:21] Bugs is hanging for me also here from home. [22:21] no problem on a 4.2-RC2 i've got installed here.. lemme try 4.2 branch [22:21] please move on; I am checking the checkins [22:22] ok, koen and crawford [22:22] will report when I have checked [22:22] next? [22:22] (thanks koen and crawford) [22:22] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5126 User name to login name mapping is broken if login name contains spaces [22:22] there _is_ a js error in that the function might be called but cannot because the function is not there. that is even on 4.2. [22:23] 5126 is not a 4.2 new bug. it was also in all previous versions. Login with a space is a bit unusual. [22:23] is that a showstopper? [22:23] this bug is not new, just recently discovered [22:23] If we lived with it so far ... we can probably wait till a patch release (4.2.1) [22:24] i suggest to reprioritize to normal (and fix for 4.2 if easy) [22:24] If it was a simple logical error ... but this could be a major update with risk of injecting new bugs while fixing [22:24] agreed [22:25] The regex to parse TWikiUsers is quite complex [22:25] --> reprioritize to normal, fix for 4.2.1 [22:25] yes. That is the decision. [22:25] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5138 Wysiwyg pickaxe destroys non-US-ASCII content [22:25] I wish Steffen was here. I cannot see this error the way he describes it. It must depend on locale settings or CPAN versions. [22:26] I wonder if Steffen runs UTF8 or something like that. [22:26] Lavr_: Does it work for you with iso-8859-1? [22:26] For me it _only_ works with UTF8 [22:26] When I tried this afternoon I could not create the problem. [22:26] I tried with the 3 danish letters [22:27] going between "pickaxe" and WYSIWYG many times [22:27] what is non-us ascii? anything with ' or ` or " on top would count? [22:27] Iñtërnâtiônàlizætiøn [22:27] so, is this bug a documentation issue? [22:27] We Steffen to describe his setting that creates it. [22:28] Steffen runs with UITF-8 [22:28] I can reproduce it with ISO-8859-1 [22:28] any implications if we ship twiki with {Site}{CharSet} set to utf8 ? [22:29] HaraldJoerg: how? [22:29] note that the pickaxe works by passing the content back to the server for DOM -> TML conversion [22:29] It is with UTF8 we have all the problems Peter so we do not ship with UTF8 for sure. [22:29] so if it affects the pickaxe, it also affects normal topic save [22:29] Lavr_: I can't agree here. [22:30] i don't seem to have problems with the pickaxe and some dutch chars [22:30] If I run TWiki with UTF8, then I see neither Item5138 nor Item4840 [22:30] Maybe it requires a non-english client also? [22:30] (default 4.2, freshly updated) [22:30] I run English windows. [22:30] I run an english Firefox [22:31] On English OS? [22:31] On german OS, but locale set to english [22:31] I am quite happy to help debug/fix, on the conditions that I set out previously [22:32] viz. that I get support from someone who uses a non-English configuration [22:32] This is why we need steffen to describe exactly how his setting is. [22:33] ok it looks like I didn;t check in the compressed versions of the JS on MAIN (ref. 5126) [22:33] checking in now [22:34] ok, lets go to next item? [22:34] Harald do you save in between to reproduce or do you just change between TMCE and Raw via the pickaxe? [22:35] Both ways destroy the content [22:35] Well I just tried on my server and no problem at all. [22:35] One item left to discuss. [22:35] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4748 Interwiki link pattern breaks SEARCH summary, again [22:36] my proposed fix is a no-brainer [22:36] Ah, now I know what you mean by the pickaxe. :) btw: I can reproduce it. [22:36] OliverKrueger: at first i though 'pickaxe' was just an euphemism for 'wysiwyg editor' too :)) [22:37] can be done in the core where the summary is created [22:37] :-) [22:37] well. If Steffen, Oliver and Steffen sees this then 5138 is a release blocker for sure. we are not shipping an English only TWiki [22:37] Lavr_: agreed, but we need more data, i cannot reproduce it.. [22:38] reproducing means: the heart symbol is translated to %u2665 and not translated back. [22:38] Heart symbol??? [22:39] &heart; [22:39] I inserted a special symbol as mentioned in Item5138. [22:39] Yes, via the Omega button. [22:40] What about normal German umlaut characters? That is what I am concerned about. [22:40] btw: german OS, english FF and iso8859-15. [22:40] * OliverKrueger checks [22:40] tim check: +40 min [22:41] umlauts look good. [22:41] OK. So the issue is not extended characters but &something; syntax characters? [22:41] tested on a rc2 installation [22:42] Maybe the omega doesn't add the correct character code? [22:42] I've just made a strange observation: [22:42] back to 4748: i am reluctant to check in a fix for 4748 since my dev env is a bit goofy and i can't run the tests [22:42] ok, I get an error "Wide character in print" when i try that [22:44] lets move on [22:44] ACK [22:44] any comments on 4748? [22:44] Peter - I can run the tests for you if you check in the code. [22:45] ok, let me do that, thanks [22:45] next? [22:45] But as late as yesterday only the TWikiRelease04x02 branch ran clean so check in there and then I run tests there. [22:46] ok [22:46] next item? [22:46] Lavr_: I fixed MAIN a few minutes after the reported test fails, so it should run clean as well (just FYI) [22:46] We are done with bugs. So we are on next agenda item [22:46] OK CDOt sounds great [22:46] Is d.t.o. down? [22:46] no [22:46] i have two more, not urgent, but i'd like to cover [22:46] Item4177: Don't Ship .pm Documentation Topics [22:46] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4177 [22:46] i'd like to stop shipping the internal docs [22:47] to reduce the chance of folks using internal functions that break on upgrade [22:47] internal docs? like TWikiFuncDotPm et al? [22:47] ah.. [22:47] TWikiFunc is good to have. We should include the official API docs. [22:47] basically we should ship only the ...dotpm that are official [22:47] not sure if i would like that... [22:47] there is no good reason to ship the internal API docs, IMHO [22:48] such as func, meta etc [22:48] this seems to be a small change [22:48] esp. since the internal APIs are POD, and can be documented that way by a dev [22:48] only manifest? [22:48] problem is, if i'm developing on an old twiki, i'd like to have the actual internal API docs there if i need them [22:48] I believe it is the build contrib that generates these docs. [22:48] We can put it into a DeveloperAddOn. [22:49] Lavr_: I think it's the build.pl for the release [22:49] this is not urgent and not a release blocker, but a nice to have to save support calls and frustrations later on [22:49] BuildContrib only generates them if you put %$POD% [22:49] Yes. The docs are not topics. Build generates them from the pods [22:49] what do we risk? [22:49] can anyone look into excluding the non published modules? [22:50] the main risk is losing the doc for EmptyPlugin, I suspect [22:50] So CDot what is the method? Remove %$POD% from sources? [22:50] dunno [22:50] I didn;t write build.pl [22:51] I imiagine it's done mechanically in there - a loop of some kind [22:51] * SvenDowideit has joined #twiki_release [22:51] here is the expert! :-) Hi Sven [22:51] :) [22:51] hi sven [22:51] holla :) [22:51] is it all over? [22:51] we just talked about Item4177: Don't Ship .pm Documentation Topics [22:51] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4177 [22:52] Sven. There is a proposal to not ship the build generated docs except for the official API ones such as Func. [22:52] HaraldJoerg: (aside on 5138: I just get wide character in print errors all the time. Help!) [22:52] if you have time, could you look into excluding non published modules from getting documented as XyzDotPm topics? [22:52] Question is - how do you unselect to generate some of them? [22:53] yes, there needs to be a manifest or something to specify which ones to generate [22:53] we'd have to make a list and check it twice :) [22:53] # Note: generated documentation files do *NOT* appear in MANIFEST [22:53] # generate the POD documentation [22:53] print "Building automatic documentation to $this->{tmpDir}..."; [22:53] print `perl $this->{basedir}/tools/gendocs.pl -debug -root $this->{tmpDir}`; [22:53] $this->cp( "$this->{tmpDir}/AUTHORS", [22:53] can't we somehow mark the ones we want to ship? [22:53] from build.pl [22:53] the fact that it is commented suggests that I may have written it .... :-/ [22:54] yup [22:54] i always felt a bit eird about generating a .txt [22:54] idea: mark it in the .pm file itself, let build.pl look for the marker [22:54] PodPlugin seems more my style [22:55] yeah, but PodPlugin is the same as shipping the docs [22:55] sven/crawford, could you look into this? [22:55] PodPlugin? is that generating them on-the-fly? iew [22:55] one more item: [22:55] Item5142: Use universal edit button [22:55] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5142 [22:55] * CDot has his hands full with TMCE, so is in non-volunteering mode [22:55] arthur: i think we whould sip twiki with the unversal edit button [22:55] i checked in the image files a while ago [22:56] the pattern skin should use the button [22:56] e.g. button and text (same text, no maketext change) [22:56] what is the status of the election? [22:56] small change [22:56] I *like* this idea [22:56] so shoudl the defult skin etc [22:56] has there been a decision? [22:56] to raise the visibility of wikis and TWiki in particular [22:56] we should re-kick the process on aboutus [22:57] as it seems to have lost momentum [22:57] actually [22:57] can we ad that to the next marketing meeting? [22:57] But please - in a 100% safe way - so much can go wrong if we change the skin again. [22:57] ward was lobbying for the universal wiki edit button at wikisym [22:57] the site has been hugely redesigned [22:57] agreed, add the button only if low risk [22:57] I've not seen a meeting request about it in months [22:57] * gmc probably misses the entire point.. [22:58] gmc - think rss icon [22:58] but for wikis [22:58] well no [22:58] the button was agreed on by consensus, but will evolve over time [22:58] it should be next to the edit label [22:58] correct [22:58] same as was done with rss button [22:58] a label for the important thing about wiki [22:58] like done for the twiki.NET skin [22:59] ArthurClemens: yes, we're saying the same thing [22:59] SvenDowideit: i fai lto see the point, but still [22:59] yes: button loks like [(X) Edit ] -- replace (X) with edit button image [22:59] so which one is it? [22:59] peter's green one :) [22:59] yes [23:00] Only the top left edit button right? [23:00] top right I mean [23:00] yes, only that one [23:00] ok, that is all i had [23:00] i need to leave in a few min [23:00] the icon is not particularly clear, if i may say so.. [23:01] Then it is release schedule next [23:01] the rss icon wasn't either [23:01] i see it is described as a crayon, but it could as well be an eraser imho [23:01] yup, and both is fine [23:01] gmc- the idea is that if all wikis have it - people will recognize it and know it is a wiki. [23:01] on meetung minute topic: [23:01] * Code freeze: 2007-09-20 for TWikiRelease04x02 branch on SVN [23:01] * Beta 1 release: 2007-09-20 [23:01] * Beta 2 release: 2007-10-01 [23:01] * Beta 3 release: 2007-11-01 [23:01] * String freeze date: 2007-11-26 (at RC1) [23:01] * RC 1 release: 2007-11-26 [23:01] * RC 2 release: 2007-12-10 [23:01] * RC 3 release: ?? [23:01] * Production release: First week of Jan 2008? [23:02] second [23:02] PeterThoeny: what is realistic for a release date, marketing-effort wise? [23:02] i sent an email asking the dev team and release mgr to label the xmas release rc3 [23:02] I guess there is broad agreement that we release as soon as possible after new year [23:02] and to release in jan [23:02] I think I will be back hom on the 6th of jan [23:03] from marketing perspective: first or send week of jan [23:03] so would target the 9th [23:03] and I think we have the quality to release now so for sure also in January. as long as we do not goof up ;-) [23:03] giving me 2 days of in case time [23:03] 9th is wed [23:03] yup [23:03] ok, sounds good [23:04] do we ahve an rc3 at around xmas? [23:04] have enough things changed? [23:04] I've been sick the last week, so not really doing much other than working for clients [23:04] the label will change to "production ready". :) [23:04] :-) [23:05] ok, i gotta run, please continue and i will see the logs [23:05] thanks all [23:05] later [23:05] cya! [23:05] (i will post the log) [23:05] cu [23:05] bye! [23:05] actually, y, ok, I'll build an rc3 on friday [23:05] just to show stability [23:06] * CDot is fretting about the lack of committed support to help him debug wide character problems [23:06] Yep. Friday is fine. [23:06] How can I help? [23:06] OliverKrueger: by testing, analysing, trying to debug yourself [23:06] utf8 and fat characters really needs a friend [23:06] I dont see that wide chat error page. [23:06] and more than anything, understanding fat chars [23:07] I guess we are done with the formal meeting. [23:07] cos they do my head in [23:08] I had to do some jiggery-pokery with wide chars to solve a crash that steffen reported [23:08] I think it is that code that is causing *this* problem [23:08] if I remove the code, this will work, but the old problem will come back :-( [23:08] another report or 5138? [23:08] It seems there is a huge difference between the character I get when I hit a Danish char on the keyboard and when I use the "omega" feature in TMCE [23:08] * CDot stands ready to hit gophers with a mallet [23:09] OliverKrueger: another report [23:09] * CDot looks for the ref [23:10] Lavr_: Yes, that's what I suspect too [23:10] Item4622 [23:10] The Omega inserts sth like this: &#nnnn; [23:11] What is key to me is that characters entered on my keyboard survives the TMCE/Raw cycle. That is essential because that is normal everyday use. [23:11] Item4840 also [23:11] I guess, your keyboard does not insert html entities. :) [23:11] there are a number of "suspects" [23:11] first, TMCE post-converts keyboard chars to entitites during save [23:12] No. when I type Danish the characters never becomes html entities. Just extended 7 bit characters [23:12] then, the HTML parser converts them back to wide chars [23:12] then the HTML2TML conversion converts them to numerical entities [23:12] too many places for it to go wrong :-( [23:13] I guess you are right. [23:13] If I enter a "heart", it is converted to an entity on save [23:13] it depends how wide the char is, i think [23:13] which codepage it is on [23:14] if I had a testcase, that would help enormously [23:16] The character I am trying with - where all seems OK - is the last letter in the Danish alpha - the a with a ring on top. (num code 229). [23:16] right; which is 8 bit [23:16] That one I can save and go back and forth between raw and TMCE. No issue at all. [23:17] try a 16 bit char [23:17] e.g. &heart; [23:17] German umlauts (all below num 255) are ok aswell. [23:17] ♥ I mean [23:17] the thing that blows up is the server [23:18] probably because of a missing encode/decode step [23:18] Yes. We have a very serious issue. [23:18] When I enter some Danish all is well. [23:18] When I enter just ONE 16-bit code and hit the pickaxe ALL the danish characters are converted to garbage as well. [23:19] That could indicate that we need to look into Perl's conversion logic [23:19] :-( [23:19] Even though they were saved in a previous version. So adding ONE 16-bit character goofs up the whole topic. That is a showstopper. [23:19] yep. the char is de/encoded to %unnnn and not back [23:20] if you read what I wrote in http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4622, you can get a feel for some of the issues I found [23:20] ok, it's helpful to know that it is 16 bit chars that are tirggering the problem [23:21] Yep. And non UTF8 setting. I run with 100% default character sets in TWiki, English OS on server, English OS on Client, English browser. [23:22] ok. so, how does perl know the difference between a 16 bit char and 2 8 bit chars? [23:24] Perl uses heuristic :-( [23:26] I can write a topic with Danish letter plus the greek letter Delta where the Delta comes from the omega menu... [23:26] I can save this and the Danish letters are 8 bit and the delta becomes a html entity. [23:26] I can edit and save and edit and save. All is still well. I can raw edit and save. All is well. [23:27] The minutes I open in TMCE and hit the pickaxe - ALL the non-ASCII gets converted into 16 bit garbage which never becomes readable letters again. [23:28] can you inspect to see what is sent to the server by TMCE when you save? [23:29] The conversion happens when I hit the pickaxe. It is already garbage before I hit save. [23:30] At least you should be able to reproduce it now. [23:31] It requires no Danish keyboard. Just use the omega menu. It produces the 8 bit characters fine. Same codes as with keyboard. [23:31] Lavr_, which charset do u use? [23:31] In TWiki I assume? [23:32] yes, in TWiki. [23:32] UseLocale On or Off? [23:32] Checking to be sure I say it right [23:33] {UseLocale} is OFF [23:34] {Site}{Locale} is en_US.ISO-8859-1 [23:34] {Site}{LocaleRegexes} is checked [23:34] {Site}{CharSet} is iso-8859-1 [23:34] {Site}{Lang} is en [23:34] {Site}{FullLang} is en-us [23:36] We use our TWiki in English and have international users. Maybe 1-2% of topics are in Danish. But we still have lots of Danish letters because of Danish names, and Danish places etc. [23:36]