Session Start: Mon Dec 11 21:59:42 2006 Session Ident: #twiki_edinburgh [21:59] * Now talking in #twiki_edinburgh [21:59] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x12x11' [21:59] * Set by SvenDowideit on Mon Dec 11 18:04:06 [21:59] hi kenneth [22:00] Good evening [22:00] * ArthurClemens has joined #twiki_edinburgh [22:00] hi all [22:00] what's new in germany? [22:00] hi arthur [22:01] Winter tries hard to get below 0 degrees C, but fails miserably [22:01] good for you :-) [22:01] I just booked my wintersport vacation [22:02] in Feb [22:02] it was also getting a bit colder here in the silicon valley [22:02] my son is into model rocketry [22:02] we are now members of club [22:03] last time we went we lost the rocket [22:03] too high up (1500m) to see where it was coming down [22:03] Back in 1 min [22:05] hi all [22:05] hi antonio [22:06] did anybody hear from crawford? [22:07] is he going to join? [22:07] I am back [22:07] ok [22:08] it's +10min, shall we start? [22:08] actually, we should try to start earlier [22:08] next time [22:08] all: please try to be in time so that we can use it effectively [22:09] kenneth and me as usual for minutes and facilitation? [22:09] anyone would like to jump in instead? [22:09] Yep [22:10] All fine if we do like usual... [22:10] if not, lets start [22:10] proposed agenda: [22:10] # 1. Review Previous Action Items [22:10] # 2. Review Proposed Features of TWiki 4.1 [22:10] # 3. Review Bug Fix Status of TWiki 4.1 [22:10] # 4. TWiki 4.1 Release Timing [22:10] anything to add? [22:11] Not from me [22:11] PeterThoeny: I would like to propose a change in the order [22:11] yes? [22:12] We should be able to do 1 in 60 seconds and 2 in 30 seconds. [22:12] since 21GMT is 18PM here, I can't stay much, so I'd like to discuss string freeze as soon as possible [22:12] s/18PM/6PM/ :) [22:13] Lavr: if 1 and 2 are quick, no problem with me [22:13] ok, then lets do string freeze rigt now [22:13] ---+ 1 string freeze [22:13] are there any pending bug fixes that impact the strings? [22:13] i mean, any big changes? [22:14] I have proposed string freeze and I agree that we should let Antonio go ahead and coordinate translation updates now. [22:14] Agreed [22:14] i also think that this is the right timing [22:14] just want to ask here in the meeting [22:15] ok [22:15] fine with me [22:15] arthur: any pending patternskin changes (printable etc) [22:15] What files are covered with MAKETEXT? [22:15] that impact string translation? [22:15] I don't think so [22:16] ArthurClemens: basically UI stuff [22:16] most of templates, some topics [22:16] and perl code [22:16] in this case i think everybody is ok with string freeze now [22:16] great [22:16] I have wondered before how to put localization in perl code [22:16] Action item recorded: * Antonio Terceiro: Facilitate that translators are notified so we can get translations done ASAP [22:16] ArthurClemens: there are plenty of examples in TWiki [22:17] antonio: can you take this as actiuon utems: ccordinate with translators to get translation going [22:17] ok. does it check plugins as well? [22:17] PeterThoeny: off course [22:17] ArthurClemens: only the main plugins [22:17] btw, nice script you created to update the string translation progress on twiki.org [22:17] it would be nice if we can settle on deadlines to translations to get into the release [22:17] PeterThoeny: thanks :) [22:18] so how can we provide translations for addons and plugins? [22:18] ArthurClemens: currently we can't [22:18] arthur: if you assume twiki 4 support only, simply add %MAKETEXT{}% to your plugins [22:19] antonio: why? [22:19] %MAKETEXT{}% in templates [22:19] PeterThoeny: because the UI interface is not visible to plugins perl code [22:19] the tagmeplugin has some maketext [22:19] the templates can be translated, though [22:19] s/UI interface/I18N interface/ [22:20] something hairy in perl code: $session->{i18n}->maketext('bla'} [22:20] if this is correct [22:20] ArthurClemens: yes. I want also to short these calls putting maketext in the TWiki ojbect [22:21] in the future, after the release [22:21] can 'bla' be a new string, or should it be an existing? [22:21] ArthurClemens: the strings are extracted from code. If it is not there yet, it's added [22:21] ok [22:21] after 4.1 we need to look at translations for other plugins as well [22:21] that's why I need to freeze string to get translations for release [22:22] on deadline for string translations, i think we need to discuss that later on the meeting (twiki 4.1 release timing) [22:22] PeterThoeny: ok [22:22] anything else on strings? [22:23] no, I gues [22:24] ok [22:24] ---+ 2. Review Previous Action Items [22:24] all done, except one: [22:24] Thomas: Update TWikiTemplates for the enhancement to Template path. [22:24] [22:24] * Awaiting feedback on TemplatePathBuginTWiki4x00 before completing documentation. -- TW [22:24] There is ONE to talk about. TW asks for feedback on TemplatePathBuginTWiki4x00. He needs it for being able to finich the docs. [22:25] thomas expects feedback on http://twiki.org/cgi-bin/view/Codev/TemplatePathBuginTWiki4x00 [22:26] His problem is basically if the current undocumented behavour should be documented or kept hidden. I assume he will not code more now. [22:26] i believe he is waiting for feedback from skin authors arthur and harald? [22:26] yes, it is not about code, it is about docs [22:26] I haven't done anything on skins until now [22:27] I know close to nothing about template/skin paths [22:27] each time a surprise [22:27] I thing app writers should know more about this [22:27] think [22:27] sorry s/harald/michaeldaum/ [22:27] I guess TW's issue will be invisible to all but the most complicated TWiki use cases [22:28] I do not recall any Support questions regarding these depths [22:28] Yes. I guess if there is no feedback the statement should be that things work as in the code. And that is it. [22:28] i remember from last meeting we felt that it was better too keep the code change, but not to document this edge case [22:29] Should that be automatically be a topic in 4.2? [22:29] can we confirm this here? [22:29] I think that was another item. The START/ENDTEXT. This is about the Template path [22:30] oh, you are right [22:30] This about documenting the Template path. [22:31] I think Thomas should document what is in the code. With the new feature the real hackers can alter the path to their desire. [22:31] thomas' comment from 4 days ago in topic: "I am fine with not documenting the strange behavior additions and leaving the code as is, but discussing this later." [22:31] That approach would be fine as well. I think Thomas and Micha are the only ones that actually play with these things. [22:31] i think this is a sensible approach [22:31] fine with me [22:31] Agreed [22:32] any objections? [22:32] SO the decision is "not documenting the strange behavior additions and leaving the code as is". [22:32] ok, done deal [22:33] ---+ 3. Review Proposed Features of TWiki 4.1 [22:33] nothing to review for 4.1 [22:33] No. [22:33] ---+ 4. Review Bug Fix Status of TWiki 4.1 [22:33] We had ONE not-yet-implemented feature and I took the initiative and move that to 4.2 [22:33] thanks kenneth for compiling the list [22:34] It was accepted in October but Cleaver had not had time to do it so it must be a 4.2 thing. [22:34] yep [22:35] on bugs review, shall we go one by one on the req/urgent ones? [22:35] Yes. We normally only discuss urgent/requirement ones here [22:35] I think that would be possible, at least for ReleaseBlockers [22:35] Bugs:Item3274 Pattern: Left bar style problems again (has a "no need to discuss") [22:36] offline between arthur and kenneth? [22:36] The "no need to discuss" means that there is an owner and no problem with spec. [22:37] do we know if this is a css issue or a code issue? [22:37] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3274 [22:37] CSS. I think Arthur simply needed access to a Windows machine to fix it. [22:37] it is css [22:37] need to find the machine tomorrow [22:38] but if I don't find a fix I can revert to previous code [22:38] sounds sensible approach [22:38] Bugs:Item3270 Bracket notation does not work for all-lowercase topic names - Needs a programmer to fix it. [22:38] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3270 [22:39] cairo had the upper case rul for initial chars [22:39] Q; why be compatible? [22:39] there was a bug in cairo where it was possible to create an initial lower case topic name (i do not now how) [22:39] why is that a bug? [22:40] because of the [[foo bar]] rul to link to [[FooBar]] [22:40] The problem is that we also have a FEATURE where [[my own topic]] becomes MyOwnTopic [22:40] if we chnage that we break existing content [22:40] I don't like reproducing bug behaviour [22:40] that is crazy [22:40] So what does [[myowntopic]] mean. [[Myowntopic]] or [[myowntopic]]? [22:40] noone will be able to remember [22:40] * Lynnwood has joined #twiki_edinburgh [22:41] hi lynnwood [22:41] [[myonetopic]] links to Myowntopic [22:41] hi lynnwood, long time no see at meeting [22:41] hi - just dropped in to see what's up. don't mind me. ;-) [22:41] yes, but [[foo bar]] is not the same as [[foobar]] [22:41] Yes based on the generic feature that [[some normal text]] becomes a WikiWord [22:41] yes, and a singleton becomes a Singleton [22:41] [[foo bar]] becomes FooBar. [22:42] That has always been a nice feature also in Cairo. [22:42] so, for twiki 4.x i think we should stick with the spec [22:42] if we cannot change that we need to document that [22:42] and fix the places where it is possible to create a lower case iniutial [22:43] I think if the topic creator and save take care for it nobody will miss more documentation [22:43] btw, similar spec at mediawiki [22:43] plus rename/move [22:43] and text is needed there [22:43] so something to add before string freeze [22:43] the reason why they can't create eRoom, but ERoom [22:44] (I thought that is why we have bracket notation) [22:44] we can document that in the TextFormattingRules topic, not affected by string freeze [22:46] no, it should be done where people are entering new topic names [22:46] If we change the bracket spec to use lower case initial letter then we loose the other feature that you can write "See my [[record collection]] for more info" and have that link to RecordCollection. [22:46] first do we have agreement on [[singleton]] becoming a link to Singleton? [22:46] is that worth the gain? [22:46] I would say it is a pain and we loose much flexibility [22:46] I would have quite many links that would be broken if we change the spec. [22:46] If it is being used then we should stick to it [22:47] I am not suggesting to change now, but I am spitting out some amazement [22:47] This has been the spec in Cairo and in 4.0.0 - 4.0.5 so we should not change that now. [22:47] i think allowing lower case initial would be confusing with current spec [22:47] by the way, this is nowhere documented in the release documentation [22:47] (confusing for coders) [22:48] how about this: keep upper initial spec as is, fix code where needed, and review link rule in 4.2? [22:48] code=javascript [22:48] there is a long pending discussion on [[foo bar]] linking to foo_bar [22:48] and add doco and user help [22:49] yeah, I thought we had a way out using TopicDisplayName [22:49] Arthur is is documented in TWiki/TextFormattingRules [22:49] but that is frozen all over [22:49] The most basic user doc we have. [22:49] You don't need much user help if it is done consistently [22:49] Laver: =[[Square bracket rules]]= let you easily create [[#SquareBrackets][non-WikiWord links]] [22:49] Forced Links section [22:49] nothing about the rules or the limitations [22:50] [[wiki syntax]] is given as example. And links to WikiSyntax. [22:50] so, action item: document the space & capitalization rule more clearly in textformattingrules topic [22:50] (action item for pth) [22:51] non-wikiword links suggests any non-wikiword link [22:51] but that is not the case and should be written ouyt [22:51] Harald: if I go to rename and check "allow non wiki word" I expect to be able to rename the topic to 'test' [22:52] Ah - you want to rename "Test" to "test"? [22:52] after that everything is horribly broken [22:52] of course [22:52] rename MyTest to test [22:53] arthur, assuming we allow lowercase initials, how would you handle existing links like [[wiki syntax]]? [22:53] wikisyntax.txt [22:53] that is, you are ok to break existing content? [22:54] or would you introduce a config flag to do one or the other? [22:54] I agree with arthur that the feature is ugly, yet I would suggest to keep it for exactly that reason [22:54] to not break links it could be WikiSyntax, and [[syntax]] could be syntax.txt [22:55] i am with harald here [22:55] well let us first manage user expectation [22:55] Arthur. Existing TWikis may have 100s of links like [[wiki syntax]]!! [22:55] And they will break if we change spec. [22:55] 10'000s of links [22:55] lets move on [22:56] talk about this later [22:56] We need to define the action items! This one is about the most basic TWiki syntax. [22:56] arthur, i agree that the current link spec is not the best (mediawiki's handling of whitespace is more intuitive for example) [22:57] but this needs to be planned [22:57] and can't be done for 4.1 [22:57] it sounds that it cannot be changed ever [22:57] with a flag it can [22:57] I would propose that the perl code for renaming is changed so that renaming and creation changes first letter to uppercase. [22:57] but this is another discussion [22:58] agreed to kenneth sugegstion [22:58] I can add some javascript as well to the rename field [22:58] Is backlinks affected, to? [22:58] also fix the topic creator to "upper case" the initial [22:58] yes [22:58] that will be "sentence capitalization" [22:59] the user reg form does the same: capitalize the initial letter [23:00] (guys, I need to leave. Please remember to define deadlines for translation updates into the release timing) [23:00] anything else on this item? [23:00] thanks antonio, please read minutes to find out [23:00] can someone take care of classic skin as well? [23:00] PeterThoeny: sure I will. [23:00] bye [23:00] * terceiro has quit IRC ("Leaving") [23:00] by t. [23:00] ok, i take the classic skin [23:01] next one: [23:01] just the rename template I think [23:01] Bugs:Item2837 Edit and FormattedSearch expands , ", %, $ in $formfield(). - Needs a programmer to fix it. [23:01] Perl code change? [23:01] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2837 [23:01] actually, summary should read: FormattedSearch expands $nop, $quot, $percnt, $dollar in $formfield() [23:01] Peter - will you take the perl change for 3270? [23:02] ironically, bug manifestated itself in summary [23:02] no, i can't commit to perl code change for 3270 [23:03] anyone taking the perl code item? [23:03] I should be able to do it [23:03] * Lynnwood has quit IRC ("This computer has gone to sleep") [23:03] Great :-) [23:03] coo, thanks harald! :-) [23:04] now on to 2837 [23:04] * Lynnwood has joined #twiki_edinburgh [23:04] I guess spec is clear on 2837. Just need coder. [23:05] two issues: 1. edit/save cycle eats $pernt etc (requ), 2. formatted search eats $percnt etc in form fields (normal bug) [23:05] anyone up to fix this one? [23:06] Do you have a clue where to start? [23:07] has to do with handling of form fields in search and also edit [23:08] if only search i'd suggest to look into the formattedsearch part of search.pm, but it is also in edit, so not sure [23:08] Ah - I just edited Item2837 (and discarded ;-) ) [23:09] So maybe it is formfield retrieval [23:09] when you edit 2837, you can restore the summary (duplicated to text body) [23:09] yes, that is a good place to start [23:10] harald, it looks like you could look into this? [23:10] ...but only if I'm finished with 3270 [23:11] AI: * Harald will give Item2837 a try. (he could need a hint) [23:11] ok, great [23:11] next [23:11] Bugs:Item3181 Incorrect template search path inherited from TWiki 4.0. Need to discuss what it takes to close this. [23:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3181 [23:11] Isn't that TW's issue from the action list? [23:11] Let me just refresh my memory and read it. [23:12] that's actually what we discussed in the action item review [23:12] Yes. We made a decision. So the closure is to do nothing about this. Right? [23:12] correct [23:12] Bugs:Item3153 INSTALL.html need to document new configure features - KennethLavrsen will action this during the next days now that the configure state is working well and dependency issues are resolved. NO NEED TO DISCUSS [23:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3153 [23:13] Yes. Now configure is finally fixed I know what to add. It will just be a few lines. [23:13] yes, the cpam dependency has been resolved [23:14] is now just a doc issue [23:14] s/cpam/cpan/ [23:14] Yes. All I will add is... [23:15] The changed method to kickstart configure (the change Harald did) [23:15] and the fact that configure can now install extensions. [23:15] And since it also handles zip only there is no long song and dance to tell. [23:16] ok, i think we are done with the requ/urgent list [23:17] kenneth listed some "waiting for feedback" bugs [23:17] I did not intend us to go through the waiting for feedback list. That was just a reminder. [23:17] i thoink we should not go through all, but i'd like to ask here which ones we should discuss [23:18] any items that needs community feedback? [23:18] There are a few new urgent items. [23:18] Item2930 Printing truncates tables [23:18] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2930 [23:18] Can we make a workaround for the FF bug? [23:18] brb., fire alarm... [23:19] ArthurClemens - you are the CSS expert. Is it possible to alter CSS for tables so that FF can print them without truncation? [23:20] perhaps using table {page-break-inside: avoid;} - can try that [23:21] If it is not possible then we have to live with it. But it is worth a try. [23:22] ...back, was a false alarm caused by smoke from the kitchen stove [23:23] few [23:24] That was actually the only new urgent bug. So we are done the bug walkthrough. [23:24] good [23:24] As a note we have 17 Actioning bugs in the normal/low. [23:24] we are in a good state now on fixing urgent/requ ones [23:24] I do hope we can do something about configure UI [23:25] it has fallen off the urgent list [23:25] If people are not really intending to action them then they should put them back in new. [23:25] What about the "discussion" bug 3243? [23:25] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3243 [23:25] Discuss between PeterThoeny and Crawford? [23:25] yes, i think this one needs some brain cycles by the community [23:26] anything this confusing should be made simple [23:26] that is: no special treatment, no edge cases [23:26] i agree in this case [23:27] One thing must be clear. Cairo did not have subwebs. If a subweb has same name as a topic then there is no Cairo spec of how to handle that. [23:27] cairo had a bug, it was treating a "web." link differently in the go box and a square bracket link [23:27] it would be nice to have crawford here [23:28] That's why I doubt there's much point in discussing it here [23:28] I have read the topic and I do not have any religious oppinion about it. I will be happy if those that discuss agree on something. [23:28] I've brought it up only because unit tests break, I never used hierarchical webs myself [23:28] i think crawford's point is that a [[Web.]] link in a FooBar topic in cairo points to a Web.FooBar topic, and in Dakar it points to Web.WebHome [23:28] Does *anyone* at our meeting use hierarchical webs? [23:29] yes - i do quite a bit [23:29] the cairo spec is a bug imho (and inconsistent with the go box behaviour) [23:29] I have one department that have played with it. But not in a serious way. [23:29] dakar does it right [23:29] I doubt many Cairo users have written [[Web.]] That is too special a case. [23:30] i never use heararchical webs, they introduce too much complexity [23:30] Crawford also pointed out that, if you are in Foo.SomeTopic, [[Web.]] could be either [[Foo.Web.WebHome]] or [[Web.WebHome]] [23:30] yes, that is the question where to start looking for hiearchical webs [23:30] Sort of relative vs. absolute links when using hierarchical webs [23:30] at current location down, or from root [23:31] this was an n/a for cairo [23:31] so it can be defined in an intuitive way for the majority of users [23:31] Yep. Without hierarchical webs, a topic with '.' is an "absolute" link, without '.' it is relative to the current web [23:32] That would also be my intuitive way of thinking. [23:32] harald, you brought the topic up initially with the question if the recent code cahnge should be changed or the testcase [23:33] i suggest to fix the testcase [23:33] That would be the pretty easy fix - if Crawford agrees [23:34] ok, let me add a note accordingly to the bug item topic, and let's see if crawford agrees [23:34] any other bug item that needs to be discussed? [23:34] +96 min [23:35] if not, let's go to: [23:35] ---+ 5. TWiki 4.1 Release Timing [23:35] first finding in print issue: removing layout.css fixes the problem [23:35] so a solution is near [23:35] good [23:36] we talked about string freeze [23:36] beta 3 seems to be stable [23:36] I have propsed a Code freeze effective from today = no more coding on features. Not even accepted ones. From now on only bug fixes. [23:36] except for some configure issues i found and some file permissions [23:36] Those are bugs. [23:37] so, are we ready for a rc1? [23:37] if so, when? [23:37] btw, thanks kenneth for building beta3! [23:37] We need to close the urget and requirement items. That seems doable in a few days. [23:37] i installed it last night on twiki.org [23:37] still testing [23:37] And we need all unit test cases to pass. [23:38] can we shoot for monday in a week, aka 2006-12-18 to build rc1? [23:38] goal is to sqash urgent/requ bugs by then? [23:39] Some practical details. I travel to Canada next week the 19th. And come back the 27th. [23:39] skiing in the rockies? [23:39] It is family visit so I assume I will have time for TWiki while SWMBO talks to SWAMBO [23:39] A = also [23:40] LOL [23:40] I will have SSH access to my Linux machines. But I cannot run benchmarks etc. [23:40] SWDMBO D= definitely [23:40] :-) [23:41] Maybe I can find an hour to build an rc1 the 18th. Otherwise I will try from remote the 20th. 19th is travelling. [23:42] Best would be Sunday night the 17th. [23:42] how bout a bit earlier? [23:42] goal is to sqash bugs by sat 16th [23:43] so kenneth can build on 17th [23:43] and thanks kenneth for jumping in on rc1! [23:43] (y) [23:43] 17th round 18:00 Central European time will be OK for me. I normally TWiki when SWMBO is in bed sleeping. Like now ;-) [23:44] oh, twiki used as a verb [23:44] i like that :-) [23:45] like "to google" someone [23:45] Should it be spelled tWiki in that case or would that break Item3270? [23:45] :-) [23:46] ok, if rc1 goes well, best case without rc2, when would we have the release? [23:46] a week later would be 25th, but not good since it is xmas [23:47] also, even if we can finish in the last week of december, i think it is better to release in the first week of jan [23:47]