Session Start: Mon Feb 04 22:01:27 2008 Session Ident: #twiki_release [22:01] * Now talking in #twiki_release [22:01] * Topic is 'http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker' [22:01] * Set by PeterThoeny on Mon Jan 07 22:13:25 [22:01] Hi everyone [22:01] * ArthurClemens has joined #twiki_release [22:01] * LarsEik has joined #twiki_release [22:02] hi arthur, crawford, colas, koen, jens, lars, martin s, sven (here?), martin u [22:02] good turnout today! [22:02] hi kenneth [22:02] hi evrybody [22:02] Hi everybody! [22:02] glad to see you back Peter :) [22:02] hi all [22:03] 2 peters even [22:03] * JensDiens1 is now known as JensDienst [22:03] and even Colas! [22:03] lars, i am happy to be back too :-) [22:03] hiho all [22:03] Hi Arthur! [22:04] minutes are at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x02x04 [22:04] well, shall we start? [22:04] our first georgetown meeting! [22:04] yes [22:05] who is facilitating, who is taking notes? [22:05] I am on the minutes already [22:05] ok, thanks [22:05] i'll facilitate [22:05] proposed agenda items: [22:05] # 1. Decision on Guidelines Sponsor Presence on TWiki.org [22:05] # 2. Review Urgent Bugs with 4.2.1 scope [22:05] # 3. Feature requests for Georgetown Release [22:06] any other items? [22:06] (there is a short one: # 4. Next meeting) [22:06] if not, lets start [22:07] ---++ 1. Decision on Guidelines Sponsor Presence on TWiki.org [22:07] Lavr, I understand you wanted to defer discussion here? [22:07] kenneth brings up a good question on the meeting topic [22:07] yes. I think there is a good debate going on on this topic and on the general governance topics also. [22:07] on one side we have an accepted decision process for features [22:08] One of the proposals that I like is that non-release decisions are taken up in project meetings instead of release meetings [22:08] some people (incl myself) think that a similar process can be applied to non-feature stuff [22:08] * peterthoeny has quit IRC (Read error: 110 (Connection timed out)) [22:08] I think that this meeting is not the right place to decide this (if there is going to be a better place) [22:09] this should be discussed at the same time as t.o look and feel, marketing efforts, etc etc [22:09] ood timing: we'll have the dev summit where we can flesh out the structure and decision process [22:09] s/ood/good/ [22:10] then let us remove this from the agenda, and add it to the forthcoming project meeting agenda (if there is one) [22:10] I agree with CDot. seems more marketing [22:10] I was thinking that a good weekly schedule would be release meeting->marketing meeting->release meeting->project meeting [22:11] 'd like to spend some cycles on the types of meetings [22:11] Ie project decisions once a month [22:11] I would really like to contribute to a "meeting" that is rather filled with "non-technical stuff" like Marketing, Governance, Usability, ... (Is there a similar meeting on such topics?) [22:11] so far we have release and marketing [22:11] one can say these are equal to features/build/release and everything else [22:11] MartinSeibert: we are talking about this on Codev [22:12] or, better, community internal affairs and external affairs [22:12] it is yet to be decided, but it seems likely there will be something like a "project meeting" [22:12] MartinSeibert: we all rely on http://twiki.org/cgi-bin/view/Codev.WebChangesForAllWebs [22:13] we could go for three types of meetings [22:13] question i have, are we big enough to need that? [22:13] I go for Lavrs proposal - let us see how that works out [22:13] If we convert every 2nd marketing meeting to a project meeting then we do not increase the meeting frequency [22:13] I don;t want more meetings, personally, but we do need a decision process [22:14] And the need for decisions is normally that for very 30 release decisions we need one project decision. [22:14] there has been much discussion on Codev; this is not the right place to overturn that [22:15] The principle should always be that anything is discussed on Codev first and only in the event of disagreement do we need to take it to a vote at a meeting. [22:15] kenneth, alternating marketing and prj might work [22:15] Like with features. [22:15] instead of alternating we could have both topics in each meeting [22:15] or on demand [22:15] not every other week we have a community decision [22:16] yes, kenneth, that is the right approach for non-feature stuff [22:16] Even for features I never bring a topic for a meeting unless the Codev discussion is at a halt. [22:17] ok, so we seem to have an agreement on the basics [22:17] details to be worked out [22:17] Please, everyone, input to the discussion in Codev [22:18] If an issue is really disagreed upon, audio confcall (skype?) may be a better medium to make people understand each other? - or email, to avoid leaving out people not able to be present on irc? [22:18] some people really dislike IRC, so yes, we should consider it [22:19] kenneth, it has been two weeks on the sponsor presence question [22:19] * CarloSchulz has joined #twiki_release [22:19] We should always accept a written vote on the Codev topic also. That i have also previously done on Feature decisions. [22:19] but the extension part is not fleshed out yet [22:19] * Lynnwood has joined #twiki_release [22:19] The sponsor decision on the release is not urgent. I do not plan to release a 4.2.1 until maybe 4 weeks from now. [22:19] http://twiki.org/cgi-bin/view/Codev/GuideLinesSponsorPresenceOnTWikiDotOrg [22:20] shall we discuss and decide today? defer to dev summit? [22:20] And the guide line has NO INPUT on the extension section. I did not want to make the initial proposal on that. [22:21] I'm happy to hear what the dev summit has to propose on this [22:21] * sshewale has joined #twiki_release [22:21] meaning, if we decide today we need to exclude the extensions for now [22:21] With respect to dev summit - we will need a morning session with virtual meeting room for any part where we will make decisions. [22:22] i sopan! [22:22] hi [22:22] Hi Peter [22:22] CDot: what are you trying to say? [22:22] Hi Sopan. [22:22] Hi Kenneth [22:23] * sshewale is now known as SopanShewale [22:23] es, kenneth, we will try to setup a conf call [22:23] so that those who are not there in person are able to participate [22:24] PeterThoeny_: ? I'm saying I'm looking forward to hearing what the dev summit has to say. Face to face discussion is always more dynamic and energetic. [22:25] The two things that need to get on a conference call part of the agenda is 1. Governance 2. Roadmap. [22:26] these two are essential [22:26] we have list more at http://twiki.org/cgi-bin/view/Codev/TWikiCommunitySummit2008Q1 [22:26] (time keeper: we have a tight program tonight) [22:27] one i find important is how to refine or dev model and how to recruit more people so that we get a more flat dev structure [22:27] time check: +27 min [22:28] kenneth: table the sponsor question for now? [22:28] Yes that it what I propose. It is not urgent. [22:28] not urgent, agreed [22:29] We have a decision for the 4.2.0 release so ... we are OK for the moment. [22:29] ---++ 2. Review Urgent Bugs with 4.2.1 scope [22:29] * Cybernd has joined #twiki_release [22:30] as part of this item, i'd like to set a tentative release date for 4.2.1 [22:30] but before [22:30] lets look at the bug items kenneth listed [22:30] TWikibug:Item5307 - Plugins with beforeAttachmentSaveHandler breaks file attachments with TWiki 4.2.0 [22:30] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5307 [22:30] this has been reported by three people [22:31] Before I begin I want to say that the arrival rate of bugs for 4.2.0 is much lower than I had feared. We have done a pretty good job with 4.2.0 [22:31] There a re no checkins on 5307; where did the piggybacked code come from? [22:31] CDot. From you [22:31] I guessed that; which bug [22:31] i reported the issue already in sep last year [22:32] CDot. You made a major svn 14070 which was a performance optimization checkin. [22:32] this bug means that public twiki sites need to downgrade to 4.1.2 because of the blacklistplugin [22:32] I think this code change got committed without you thinking about it. [22:32] Peter. Not all. I use BL PLugin and I do well with 4.2.0 [22:33] There is some special condition that triggers the bug and I cannot pinpoint what it is. [22:33] ideally we create a patch quickly so that public 4.2 twikis are safe [22:33] One common thing has been debian etch [22:33] sorry, I'm just catching up on this. it wasn't flagged for feedback, so I haven't read it before. Will comment shortly. [22:33] my internal site where i have the blp installed shows the bug, since sep last year [22:34] PeterThoeny_: at what rate does it shows? 10%? [22:34] We asked for you to debug this for a long time Peter and you decided yourself that it was downgraded to normal. [22:35] And I never saw it and I have tested a lot with BL plugin as well as RevCommentPlugin. [22:35] no, i did not downgrade it, someone else did i think (anyway, not the point) [22:35] At work we run RevCommentPlugin and I have attachments from users daily. We do not see the bug either. [22:35] yes, it is dependent on the env [22:36] It does not seem to be perl version. It does not seem to be CGI version because it is the same we use. [22:36] It is not file::temp because that is also the same rev [22:36] OK, I suspect this is to do with CGI version [22:36] And most of the CPAN libs listed in configure are the same [22:36] no, i upgraded to latest cgi, still bug [22:37] No CDOT. We use same CGI version and some of us have it and some don't [22:37] It is not related to CGI version. [22:37] when the upload stream is closed, CGI may be automatically unlinking the file (I saw a change to that effect) [22:37] which would cause this effect [22:37] seems more like the underlying c libs handling io [22:37] might be [22:37] ok, next item? [22:38] Yes. It can be kernel version based. Differences on when files are actually committed and closed by the OS [22:38] ep [22:38] yep [22:38] One observation is that reverting the code in 14070 - not all - just the 7-8 lines listed - fixes the problem with the reporter. [22:38] Peter can you try and confirm this also? [22:38] TWikibug:Item5311 - deep recursion in getEmails() [22:39] I will also try and get the 3rd reporter to confirm this [22:39] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5311 [22:39] 5311. Mainly a hit to Michael Daum to merge in fix to T42 branch [22:39] it's a rather obscure case, IMHO [22:40] you have to have a user "fred" who is in a group "fred" [22:40] split personality? [22:40] Yes. the actual case is insignificant. [22:40] it's significant when deciding whther a patch is needed or not [22:40] as Michael says, that the default in many unixes to create group foo when your create user foo [22:40] Question is if the generic core bug should be fixed on T42. Michael says yes but has not merged fix yet [22:40] TWikibug:Item5176 - is added twice in TOC links on Windows [22:41] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5176 [22:41] On 5176: A reporter says the same is the case in Linux [22:41] We have two reporters of the same bug now [22:41] the bug should be renamed [22:42] yes [22:42] Done [22:42] Who is taking a look at it? [22:42] hmmm, curious. Why is the Edit Help link pointing to the edit script and not the view script :-/ ? [22:44] who is looking at this bug? [22:44] I can try [22:44] great [22:45] cool, mercy beaucoup colas [22:45] TWikibug:Item4946 - urlDecode() not working for characters represented by Unicode code points [22:45] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4946 [22:45] The old I18N bug [22:45] yep [22:45] we still need an I18N champion [22:45] Note that the fix I rejected to include in 4.2.0 is reported to not work either. [22:46] Sopan this may be a good one for you to take a stab at. [22:46] I have my doubts about the failing testcase, but for sure the bug causes WYSIWYG to fail in Chinese. [22:46] wow, that's a big ask [22:47] but it would be great if *anyone* could look at it [22:47] in fact, the more the better [22:47] Even some analysis would be good at the moment. [22:48] Sopan seems offline if my IRC cleint is right [22:49] this bug should be fixed if at all possible for 4.2.1 [22:49] I have to leave again :( - hi&bye - could the rearrange of svn be added to this meeting? [22:49] Well. We need someone with an I18N environment or rather a non-latin + some I18N knowledge to look at this. Until then this bug will not move. [22:49] (sorry to be late) [22:49] SvenDowideit_: k [22:49] Sven - rearrange - I think there is a consensus there. [22:50] yes [22:50] Sven doesn't think it's worthwhile [22:50] TWikibug:Item5288 - META tag doesn't call expandStandardEscapes() and crashes on MAIN [22:51] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5288 [22:51] 5288: I believe it is a MAIN thing only. [22:51] I think it is worhtwhile moving to trunk - but the moving of plugins feels a little un-useful [22:51] so an n/a/ for 4.2.1 [22:51] I need my assumption confirmed. [22:51] It is easy to reproduce. Even bugs crashes [22:53] so who ever did the unique code on MAIN should take a look at it [22:53] do we know who to ask? [22:54] I think there are one or two that have checked in unique code on MAIN. So yes ;-) [22:54] TWikibug:Item5283 - EditTablePlugin dollar percent expansion does not work correctly [22:54] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5283 [22:54] Yes. This is a serious one - at least for us at Moto [22:55] Arthur it was your change. problem is that you no longer can use CALC in Edit Tables and have them working when you add rows. [22:55] And it is very common to use CALC inside an edit table. [22:55] you mean that CALC is expanded during editing? [22:55] No. it is not expanded during viewing. [22:55] or should? [22:56] The $percntCALC is not working. [22:56] because the SpreadsheetPlugin runs before the $percnt gets translated into %. [22:56] so the spreadsheetplugin never sees the CALC as %CALC [22:57] it is it the concept of saving $percnt that does not work because of the way that the order of plugin execution is [22:57] I don't have any alternative [22:58] Then it is better to go back to the way it was. [22:58] except for totally revoking [22:58] problem is that there is no workaround for this bug. [22:58] that means that any %Y% is expanded to [22:58] yes. %Y% works. %CALC...% does not [22:59] we could try to make an exception for CALC [22:59] and it is the %CALC you often use to calculate in table. That is what that plugin is made for [22:59] as dirty workaroud [22:59] I could live with a dirty also [22:59] would have to try that, not sure [22:59] I have spent ages with that plugin [23:00] yes. I know. besides this one that plugin is really great now. I have very positive response on the other fixes done and the new move and delete feature [23:00] VERY positive reponses [23:00] :-) [23:01] it is good to spread good feedback! [23:01] well that is nice [23:01] I can do one more try for CALC [23:01] Thanks Arthur. [23:01] such as vicki brown's comment on the slideshowplugin [23:02] yes saw that [23:02] "Just wanted to say how delighted I am witrh this plugin. I "scared" a co-worker last week. He saiid "There's PowerPoint? in my TWiki page!" :-)" [23:03] time check: +63 min [23:03] for 4.2.1 i am fine with a quick & dirty solution just for CALC [23:03] TWikibug:Item5118 - Difference from 4.1.2 - 4.2: Apache loginname no longer works with access control lists [23:03] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5118 [23:04] I think it says Sven all over that [23:04] it was a bug we deferred from 4.2.0 [23:04] i believe this is an important one in corporate settings [23:05] It would be good to have this fixed. I have put the reason in the bug report. [23:05] yes, it needs to be fixed [23:05] TWikibug:Item5135 - EditTablePlugin must disable initsort when editing table TABLE tag to work with new move row feature [23:05] I am happy I told my users that only WikiNames work in access rights. Otherwise our setup would have been more affected [23:05] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5135 [23:06] 5135 is one I have tried to fix. But that code is getting quite complicated. I have put a lot of analysis in the bug item. [23:06] There is a work around for it. But would be nice to have fixed. [23:07] yes, it is difficult [23:07] I wonder if we are on the right track [23:07] do you solve it by making tableplugin aware of edittableplugin url params? [23:08] No Arthur and I decided to let EditTablePlugin "hack" the TABLE tag. [23:08] This happens if EDITTABLE comes before TABLE on two seperate lines [23:08] ETP adds a new parameter to TP [23:08] to not sort [23:08] so TP is aware of it already [23:09] it is definitely out of scope of 4.2.1, but this expansing issues seem to indicate we maybe go to some kind of real "language" instead of twiki vars [23:09] and in the meantime, just go dirty to fix [23:09] it could be solved in the tp by disabling sorting if tehre are etp parameters in the url [23:10] The problem is that we parse the topic line by line. When we pass the TABLE before EDITTABLE we need to go back one line to add the option. I have been afraid to code that. [23:10] did we try the url param? [23:10] A prof programmer can make this work for sure. [23:10] we discussed it [23:10] but not sure if we went that way [23:11] time check: +70 min [23:11] or perhaps I have removed your code [23:11] that did that [23:11] The URL param we have up on because then it becomes difficult to know which EDITTABLE number matches which TABLE. [23:11] ah yes [23:11] You do not always have a TABLE with an EDITTABLE so the number is not always in sync. [23:11] we don't want to disable sorting of all tables because you edit one [23:12] Exactly [23:12] one can argue that it does not matter which table, because when a user hits edit on a table, it is only table edit that is relevant, not any sorting elsewhere on the page [23:12] e.g. all sorting can be disabled if there are etp url params [23:12] We are nearly there with the feature. It just need someone more experience than me to do the code change. All the analysis is there in the bug item [23:12] you might get some inspiration from the EditRowPlugin code. It parses TABLE and EDITTABLE robustly, AFAICT. [23:13] peter I have an example where I have two tables and I look at one when I edit the other in real life. [23:13] the code is very different [23:13] k [23:13] back :) [23:13] anyone? [23:13] hi sven [23:14] heya :) [23:14] Sven we said that 5118 was your domain. [23:14] yup [23:15] We have one bug left. I forgot to add the number. [23:15] The Preview feature we removed from Wysiwyg [23:15] last bugs item: [23:15] How do we bring it back - and do we want to bring it back? [23:16] Our preview feature based on hitting the browser back has always sucked anyway. [23:16] IMHO [23:16] I wonder who is missing the preview page [23:16] personally i use preview rarely, i would be ok to not bring it back [23:16] I have heard no complaints [23:17] I'd think we should better implement something people are noe used to instead with blogs: save in "draft" mode, [23:17] and forget preview [23:17] that might be something for a usability test [23:17] i agree with colas [23:17] s/noe/now/ [23:17] that would also add the infrastructure to do background saves [23:17] without needing to ask the user [23:18] yes, that makes sense [23:18] that could then be saved / discarded later [23:18] Sven, agreed [23:18] it does make life more interesting though [23:18] the difficulty then is how to find it back [23:18] your draft [23:18] dropping preview is worthwile if it saves energy for doing these instead [23:18] as its essentially making short term branches on the server [23:18] why not just delRev? [23:18] do we have consensus to go away with preview in wysiwyg for 4.2? [23:18] The rest method currently used to go between Wysiwyg and Pickaxe also seems like a possible method to go from preview and back to Wys or Pickaxe [23:19] cos user still like to close the browser and expect it not to be visible [23:19] If you close browser without saving all should be gone yes. [23:19] Lavr_: that would work, but only if you added a massive new rest function [23:19] yes, to prepare a page and publish it later [23:19] talking CMS almost [23:19] I would like that to work for non-wysiwyg too [23:19] so it could be more an extension to save [23:19] right now I'm not hearing a lot of demand for this [23:19] no need for more restin [23:20] no, more a WIBNIF [23:20] I also get no demand for AJAX [23:20] The other simple way is to pop-up the preview in its own window with no other control than close window. [23:20] ok, we decided to drop the preview in wysiwyg [23:20] ok. Well, i think it's wise to abandon preview, because it dosn't look like the FF bug will get fixed any time soon [23:21] popup is quite bad if it is large [23:21] current popups are small but too small to see a preview [23:21] any other bugs items? [23:21] because we have the repRev feature I can live without preview. [23:22] popups are trivial [23:22] what is the repRev feature? [23:22] TWiki.Plugins.JSPopupPlugin [23:22] _has_ a popup preview [23:22] repRev = not increasing revision if same user saves within certain time limit [23:22] and a popup oopsmore, and a few others [23:22] ok, can we shoot for a target date for 4.2.1? [23:22] too early? [23:22] too early for me :/ [23:23] I am in USA from 8th and back in DK on the 20th. [23:23] I can handle a patch release alone - I would suggest I do one 4 weeks from now. [23:23] set tentative n two weeks, feb 18? [23:24] 18th is between 8th and 20th. [23:24] so no [23:24] i'd be nice to get a patch for Item5307 so that public twikis are safe [23:24] s/public/affected public/ [23:25] Well. If reverting the 7-8 lines is an OK fix then we already have the patch ready. [23:25] I was suprised that I was the only one to respond to the recent security questions [23:25] i am fine with 4 weeks from now [23:25] CDot you responded well. [23:25] with the patch [23:25] Lavr_: reverting is not an option. I can explain offline. [23:26] CDot. Old code worked for all. New code does not work for many. [23:26] * SopanShewale_ has joined #twiki_release [23:26] So fix is needed [23:26] Follow up on the bug item CDot. We seem to have two responsive bug reporters to work with [23:27] Any of us running debian etch? [23:27] don't knee-jerk respond until I have had time to analyse. I was not aware of this issue before tonight, [23:27] I run debian etch [23:27] I, but I didnt see the bug [23:27] and I cannot reproduce it - yet [23:27] * SopanShewale has quit IRC (Read error: 104 (Connection reset by peer)) [23:27] still trying. [23:27] * SopanShewale_ is now known as SopanShewale [23:27] * SopanShewale has quit IRC (Client Quit) [23:28] lets move on [23:28] ---++ 3. Feature requests for Georgetown Release [23:28] It could be hardware depending also. Like how much HD cache or SCSI, vs ATA vs SATA. Different drivers [23:28] mebbe. [23:28] I put 3 feature requests on for decision. [23:28] # AddIsEmptyToIFVariable - Add an isempty operator to the IF vairable - Developer: RafaelAlvarez - Concern raised: CrawfordCurrie, KennethLavrsen [23:29] http://twiki.org/cgi-bin/view/Codev/AddIsEmptyToIFVariable [23:29] I need to refresh myself also. I had forgotten that I had reservations also [23:29] I withdrew my concern. [23:30] although not strictly needed, it would be nice to have the simple syntax [23:30] right [23:30] it's a common idiom, so... [23:30] it makes more readable code [23:30] really? [23:30] I think my reservation was only the scope. I am OK with having this in 5.0 [23:30] seems everybody on board? [23:30] I often wonder what 'emtpy' means [23:31] I'd say yes too [23:31] undefined [23:31] SvenDowideit_: "empty" is what normal people call "undef" ;-) [23:31] # MoveToJQuery - Enhance PatternSkin to use jQuery - Developer: ArthurClemens - Concern - SvenDowideit, MichaelDaum [23:31] why not say isundefined then? [23:31] http://twiki.org/cgi-bin/view/Codev/MoveToJQuery [23:31] time check: +90 min [23:31] because it doesn't mean that [23:31] it means isundefinedoriszerolength [23:31] wala :) [23:32] isnotvalidstring() [23:32] what happenes if i call isnotvalidstring(32) [23:32] SQL uses ISNULL, IIRC [23:32] anyway, jQuery [23:32] I no longer understand this proposal [23:32] in bash: test -z :-) [23:32] I am not sure what the concern is now [23:33] my concern is simple :( [23:33] Arthur I think we need clarification on what isempty means [23:33] I don't want to be forced to have jquery [23:33] Sven proposes to add a common TWiki layer [23:33] LarsEik, no [23:33] Lavr_, I don't have a concern for isempty that we need worry about [23:33]