[21:01] Good evening everyone. [21:02] Hi there. :) [21:02] Hi Markus [21:03] MoinMoin [21:03] hi andre, babar, crawford, kenneth, oliver, sven (here?) markus [21:03] * Lynnwood has joined #twiki_release [21:03] hi lynnwood [21:03] * EugenMayer has joined #twiki_release [21:03] Hi Eugen [21:03] babar, could you please interoduce yourself? [21:03] hi eugen [21:04] Babar is in away-mode. [21:04] s/interduce/introduce/ [21:04] hi there. if it's ok, i'm just going to listen in as i've got a deadline i'm working under [21:04] hi there [21:04] Hello togther [21:04] don't think i have much to contribute to the release discussion, but if something comes up, ping me. :-) [21:04] i have a hard stop at +60 min [21:05] * AndreU_ will also just have 1/4 eye on it [21:05] Andre you have one small but KEY role ;-) [21:06] this meeting is a regular release meeting [21:06] we had two meetings on governance [21:06] this one is about bug fixing and features [21:06] * MartinCleaver has joined #twiki_release [21:06] agenda at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x07x21 [21:07] hi martin [21:07] PeterThoeny_: hum... introduce? I'm OlivierRaginel, if that helps. Not sure I can be of any help here but I wanted to see first. Hacked a few twiki installations in the places I worked, and fixed a few things, so might help if needed. [21:08] * CDot resists the temptation to ask if there is an elephant in the room [21:08] welcome olivier [21:08] please chime in [21:09] * PeterThoeny_ wonders if the elephant is the wikiringbot? [21:09] who is facilitating today? [21:09] who is taking notes? [21:09] I am on the notes (as usual) [21:10] thanks kenneth [21:10] and i can facilitate [21:10] Peter, the wikiring bot is just a logger bot, as always. I was referring to http://en.wikipedia.org/wiki/Babar_the_Elephant [21:10] proposed agenda: [21:10] # 1. Review Urgent Bugs with 4.2.1 scope [21:10] # 2. Feature requests for Georgetown Release [21:10] anything to add? [21:10] We need a bug fixer Bot :-)) [21:11] :-) [21:11] I can see we need to take care of the classification. There are new urgent bugs that only relates to trunk. [21:12] ---++ 1. Review Urgent Bugs with 4.2.1 scope [21:12] I am a little afraid the stand alone thing will take all attention away from the 4.2.1 release [21:12] We had a very short list of urgent bugs just a few days ago but it has grown again [21:13] I will pick out only those that need discussion [21:13] a good motivation to release 4.2.1 to get more time to play with the new toys. :) [21:13] we are close to 4.2.1 release, lets focus on this release, and worry about making trunk stable after the release [21:13] Item5562: Query type Search does not report with large number of topics [21:13] Can ANYONE reproduce this one? [21:14] nope [21:14] I do not have a Windows installation to play with. [21:14] no - and i run XP with well over 150 topics [21:14] What does mean "report" ? [21:14] though I confess I use NativeSearch [21:14] report = hit? [21:15] He claims that Query searches can only return 150 results. [21:15] * OliverKrueger did not test on a XP machine. :-/ [21:15] Why 150? [21:15] we speak "server sided" ( not that i get confused about the os thing ) [21:16] could it be a CGI memory limition of his setup ? [21:16] Yes. server side XP [21:16] I *am* talking about server side [21:16] Can there be an old bug in 4.2.0 that was later fixed? [21:16] * Soronthar has joined #twiki_release [21:16] He uses t.o version of 4.2.0. Not SVN checkout [21:17] Lavr_: none that I am aware of. [21:17] * etherbob has joined #twiki_release [21:17] i suggest to downgrade this to normal because it is hard to reproduce and we have many urgent bugs fixed for 4.2.1 [21:17] i cant think about other reasons to "stop" on 150 topics beside memory exceeding or script-run time limit ( what we dont have in perl? ) [21:17] hi rafael, hi etherbob [21:17] Hi all [21:17] Yes. He needs to provide more info and upgrade it to urgent himself when he has more info. [21:17] Hello [21:17] howdy [21:17] can't stay long [21:17] etherbob: welcome here, could you please introduce yourself? [21:17] Sounds reasonable Lavr_ [21:18] Let me find the next to discuss [21:18] Drew_Stevenson (my irc client keeps defaulting to my old nic) [21:18] EugenMayer: it may be a shell limit with XP. I use NativeSearch, so I don;t see shell limits. [21:18] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5382. [21:18] Item5382: TWiki.pm sets wrong urlHost if https protocol and ShorterUrlCookbook is used [21:19] Sopan checked in a fix which broke 9 unit tests. [21:19] * ktwilight_ has joined #twiki_release [21:19] hi all [21:19] hi [21:19] still broken [21:19] he suggests a new fix. He wants feedback [21:19] He has a fix suggested in the report [21:19] search splits up pages into chunks, there is a variable to set the number of topics to search at a time. for debug the person could lower that. this is not a configure setting, it needs to be done in the core [21:19] I discussed it with Sopan on IRC. Fixing the code to make the testcases pass is wrong, because the testcases are wrong. [21:20] Does this mean the code is good as it is now? And only unit tests are broken? [21:20] Only? [21:20] yes only [21:20] The failures may be masking other, more serious, problems [21:21] there is no "only" [21:21] * CDot has his Yoda face on [21:21] * Lavr_ pricks CDot in the eye [21:21] :-) [21:21] watch it, I have a light sabre and I'm not afraid to use it [21:21] Naturally we need the unit tests fixed. Sopan was unsure about his fix [21:21] i also talked to sopan about this, mainly a testcase issue [21:22] Can Sopan fix the test case? [21:22] yes, he is working on it [21:22] he seemed to think he could [21:22] OK. We take the next then [21:22] Item5707: "tml2html did not send an HTTP header" error makes WYSIWYG editor unusable [21:23] time check: +20 min [21:23] Again a reproduction issue [21:23] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5707 [21:23] hmm one second, what does the header have to do with it being unusable ? [21:23] one second [21:23] I beleiev him when he says there is a problem; I just can't reproduce it. [21:24] EugenMayer: you need to read the report; the headline is misleading. [21:24] Eugen - you may try and reproduce it if you can. Otherwise I will defer it. I will not let this block a release [21:24] Normal behaviour for CGI is to pass form parameters through as encoded UTF8 [21:24] coudl you change the headline to a more descriptive one? [21:25] i use the WYSIWYG editor, but on 4.1.2 base [21:25] it *is* possible to configure it to *decode* the UTF8, which is what is happening here [21:25] * Babar had this issue when trying ShorterUrlCookbook. This kills the rest script that WysiwygPlugin uses. Not sure it's related though [21:25] Babar: were you using high bit characetrs? [21:25] i had some issues and i rewrote some stuff ( i added support for forms + WYSIWYG ). so i cant really be a testcase [21:25] becasue my code is "changed" [21:26] Me has 4 parallel TWiki's installed just for testing. [21:26] * /me: insufficient parameters [21:26] CDot: in the page? Define high bit please. [21:26] Babar: e.g. cydillas, acutes, accents etc [21:26] german umlauts ie. [21:26] i suggest to downgrade this to normal. issue affects one customer so far [21:26] ok, so most probably yes [21:26] PeterThoeny_: agreed [21:26] Lavr_: iam begind you :) But iam young, ill catch you! [21:27] I need someone who is prepared to debug it quickly. [21:27] cos until i can reproduce it, it's not a problem :-) [21:27] It is probably related to a specific Apache setup. [21:28] maybe; dunno. [21:28] I think it could be more browser dependent [21:28] I seriously doubt that. [21:28] would be good if there's a VM that anyone can access it to replicate the problem. [21:28] that'd narrow down the problems lots. [21:29] EugenMayer: yes, it might be. Again, I don;t know. [21:29] i had some problems with encoding days ago, when using jquery / prottype and ajax ( thats what we use with restHandlers ). But it was PHP and has been solved by setting header [21:29] If it was client side we would see this reported everywhere. I would have my Motion users cry all the time [21:29] in addtion, urlencoding is importing with ajax, but you do this already in the code, as far as i could see crawford [21:29] right [21:30] Lavr_: do you use UTF8 with Motion? [21:30] No. [21:30] So, move on i guess ? [21:30] until we got a reproduceable testcase [21:30] next Item5729: a redirect quits cgi process before finishing the twiki object [21:31] Michael raised it and some debate and then no further progress. [21:31] Seems to be serious when running mod_perl [21:31] or simiar [21:31] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5729 [21:32] I have no idea what is being reported here. MD jumped to a comclusion that is (I am fairly sure) wrong [21:33] Had anyone seen MD the past 3-4 days? [21:33] Is he on vacation? [21:33] time check: +30 min [21:33] it requires a much more detailed debug than anyone has given it yet. [21:33] hmm, session is build even before any UI scope? so it cant really get lost when dieing in UI ? [21:33] Lavr_: dunno, i haven't seen him. [21:34] reminds me... yes, that's the issue with the other bug... mod_perl breaks WYSIWYG editor on my installation too [21:34] Its holiday time where he lives and he has children... [21:34] Oliver that is what I thought. [21:34] Babar - raise a Bug item if you did not already do. [21:35] (nice English I composed there) [21:35] Lavr_: my 2ct ... ;) [21:35] I'm not aware of him benig on holiday. However he does have a very pushy client at the moment. [21:35] is 5729 a release blocker? [21:35] no [21:35] i guess it could be [21:35] Lavr_: it's the same as 5707 [21:35] OK let us downgrade 5729 then. [21:35] but I didn't know it was linked with utf-8 (and I doubt it, honestly) [21:35] Item5796: SubscribePlugin and perl 5.8.4 exposes a taint issue in the latest MailerContrib [21:36] is t.d.o accessble? 'cuz i see a "server not found" [21:36] i agree that this is urgent for mod_perl users, but not a blocker for 4.2.1 [21:36] that requires support from a 5.8.4 user to isolate the problem [21:36] ktwilight_: yes, it is [21:36] anyone got 5.8.4? [21:36] I am on 5.8.8 and have a VM of 5.10 [21:36] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5796 [21:37] 5.8.8 [21:37] checkin [21:37] Lavr_: ditto [21:37] hi kwang (missed you when you joined) [21:37] 5.8.8 :/ [21:37] me too (5.8.8) [21:37] Sven has 5.8.4 on Solaris, apparently it is the version shipped by default [21:37] me3 [21:37] PeterThoeny_, hi peter :) [21:37] which version of SubscribePlugin and MailerContrib? I use both with 5.8.4, have not seen any issue [21:37] It is Sven that reported it and it requires a combo of a specific plugin. I downgrade to normal. [21:37] Soronthar: latest? [21:38] hmmm... let me see [21:38] Look at the error, does it has even something to do with subscribe ? [21:38] Soronthar: I did check in some updates a month or two ago, and Sven thinks it is related [21:38] it seems to happen in the Form code, for me it looks like something form related ? [21:39] EugenMayer: SvenDowideit_ reckons the taint error is in MailerContrib::_load, which is plausible [21:39] but IMHO very unlikely [21:39] so, I regard this as hearsay until it is reproduced and analysed [21:39] strange, the whole callstack does not include anything with MailerContrib. But as its sven, he should know what he is talking about [21:39] we can't ask users to upgrade from 5.8.4 to 5.8.8, debug takes time, but fix looks easy: one line to untaint something [21:40] Peter i think, this fix will just casue other things broken [21:40] PeterThoeny_: it's not that simple. There is nothing tainted. It is just perl throwing a taint error, apparently [21:40] our first reaction was that this is a perl bug [21:40] but it requires further analysis [21:40] something coming out of the URI is tainted [21:41] no, i don't have the latest changes. [21:41] well, that taint error in perl is likely caused by a parameter passed to a perl lib [21:41] no, because the same code works with 5.8.8 [21:41] when its passed to the script ( by e.g. subscription var or something ) it will cause a tained error [21:41] we will not solve this here. [21:41] fine [21:41] It seems Sven is the right man since he can reproduce the problem. But will he? [21:41] (unless Soronthar can debug, which would be most useful) [21:41] problem identified, needs to be fixed [21:42] release blocker? [21:42] problem identified ? [21:42] must missed that :/ [21:42] "a problem has been identified". Doesn't mean we know what it is, yet ;-) [21:42] tup [21:42] yup [21:43] ok, what does that mean? We know, there must be an error? [21:43] I'll take a stab at it this week [21:43] Thanks [21:43] thanks rafael!!! [21:43] Soronthar: thanks Raf. Give me a shout if you find anything. [21:43] sure [21:43] :) [21:43] Next is Item5718: SEARCH shows different results depending on limit [21:43] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5718 [21:43] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5718 [21:44] somehow it sounds familiar... [21:44] Sopan tried to reproduce. So have I. [21:44] * etherbob has quit IRC [21:44] We know the results are wrong if people have manipulated with the files editing or copying. [21:44] And I still have some doubt if this did not happen in this case. [21:45] No indication of the server. i wonder if this could be the same problem as the XP report? [21:45] Could be [21:46] You mean the "150 hits" limit? [21:46] y [21:46] Then he wouldn't get any results for Limt >150, would he? [21:46] Though the 150 bug did not try to sort for date [21:47] time check: +45 min [21:47] I don't know. I can't guess what is going on here. It *sounds* like PEBKAC. [21:47] ? [21:47] I seem to recall (last time i was the search code) that the ordering was not predictable [21:47] if there was a limit (I found that while trying to page the search results) [21:47] search with sort on date assumes proper file timestamps [21:48] The ordering is first done per file time stamp - for speed. If files have been copied or edited the result will be all wrong. [21:48] e.g. it fails if a script updates all topics in a q&d way (bypassing twiki api) [21:48] the most likely explanation is that the file times were changed by a non-twiki agency [21:48] Something we can much better address in 5.0. But shoud not attempt to fix for 4.2.1 [21:48] downgrade to normal [21:48] OK will do [21:49] Next is a Wysiwyg bug Item5659: scrambled output on edit [21:49] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5659 [21:50] Seems the reporter "got it to work". So no action [21:50] reads like the user resolved their problem themselves, which is why I didn;t comment [21:50] though diabling and re-enabling the plugin would be a NOP, so I suspect some other step was involved [21:51] 5799 is a trunk only bug (Gilmar) [21:51] so we skip that [21:51] yes [21:51] Item5787: square bracket url links don't escape their contents well enough [21:51] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5787 [21:52] I would downgrade this to Normal. It cannot suddenly be a release blocker and Sven can fix it even if it is "Normal". [21:52] Anyone against downgrading to normal? [21:52] agreed [21:52] Item5792: BugsContrib's WebRss broken - Michael Daum. [21:52] * grim_fandango has joined #twiki_release [21:53] not a blockwer [21:53] Agree [21:53] i think 5787 is an n/a [21:53] the reporter puts this as an example: [[http://home.org.au/Some FileName that looks interesting.jpg][testing the file]] [21:53] spaces are not suported in a url, they need to be escaped with + or %20 [21:54] yap [21:54] Then please N/A it right away as I continue. [21:54] OK. A big one. Item5437: UTF-8 fixes for TWiki 4.2 [21:54] I was just testing that :) [21:54] * peterthoeny has joined #twiki_release [21:54] Do we need more UTF8 fixes for 4.2.1 or are we OK for now [21:54] ? [21:55] sorry, someone unplugged the power cord of the router [21:55] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5437 [21:56] I think we release 4.2.1 if we attempt to be clean on UTF8. [21:56] I try again [21:56] I think we release 4.2.1 IN DECEMBER if we attempt to be clean on UTF8. [21:56] December 2009 [21:57] :-) [21:57] yes, time to release, with known issues [21:57] So I think we should leave it where we are. You can edit in UTF8 now but things like Wikiwords are broken with highbit chars. [21:57] People editing Chinese only will not need WikiWords with highbit. [21:57] So we are still much better than in 4.2.0. [21:58] UTF-8 will be a major focus for 5.0? [21:58] Item5451: MailInContrib reveals error in Password.pm, that has been carried over to LdapContrib [21:58] or there will be further improvements in the 4.X family? [21:58] Soronthar: if - and only if - one or more UTF-8 using people take a lead [21:58] Michael is working on it it seems. Was it just a matter of renaming a sub? [21:59] yep [21:59] I wonder why that was not closed 5 months ago ?? [21:59] no idea. [21:59] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5451 - MailInContrib reveals error in Password.pm, that has been carried over to LdapContrib [22:00] Lavr_: just for the record, I think bug 5707 is linked with rest being called with mod_perl and not through CGI. I've commented in the bug anyway, but my installation now works with mod_perl [22:00] i need to sign off in a few min [22:00] Babar: thanks [22:00] Thanks Babar. Anything you can add of info is a help [22:01] next? [22:01] The 5118/4824 pair. Anything missing? [22:01] (I will facilitate when Peter goes) [22:01] Lavr_: just the sudo login [22:01] That has its own bug report I believe. [22:01] which I can't reproduce [22:02] waiting for you guys to give me a howto [22:02] You cannot reproduce the sudo login problem?? [22:02] nope [22:02] thanks crawford [22:02] I can. I will make a howto [22:02] works poifectly for me [22:02] bye Peter [22:02] time check: +60 min [22:02] Note that I ONLY test in 4.2. code. I have not verified same bug in trunk. [22:02] by all, please continue with bug review and feature proposals [22:02] please try to set a release date for 4.2.1 [22:03] Lavr_: I tested in both. [22:03] The sudo login bug is for some reason not maked urgent. That is a mistake [22:04] CDot. Did you test with ApacheLogin? [22:04] Lavr_: no, template. [22:04] you didn't specify [22:04] I am sure it may work with TemplateLogin. It is the mix of ApacheLogin and the sudo which is a Template type login that may be the trigger [22:04] The original reporter did not specify and I did not notice he did not. [22:05] didn;t think of it; I never use apache login [22:05] Then it is good I test 90% in ApacheLogin :-) Because this is how I do at work with LDAP. [22:06] we seroiusly need to consider a central test box. that'd help speed things up... [22:06] ktwilight_: boxen [22:06] works too. [22:06] I have made one available since 2006. merlin.lavrsen.dk [22:06] Contains a Cairo, a 4.1, a 4.2 and a trunk [22:06] but is it accessible for any devs? [22:07] SvenDowideit_ has done a good job setting up a regular cron, but other test resources are scattered and disorganised [22:07] register and test. You need my help to change configuration though. [22:07] really need coordination. [22:07] so instead of bouncing back and forth of configs, let's allow anyone ssh into those boxes as test beds [22:07] My merlin.lavrsen.dk would need to be isolated then. Until recently it was also my mail server. [22:07] Lavr_: I would be prepared to release my multiple-twiki management console to you if it would help. Talk offline. [22:08] Thanks CDot. [22:08] i can prepare a debian test bed for twiki (anyone) if needed. [22:08] it'll be isolated of course. :) [22:08] We are through the urgent list :-) [22:08] what is really needed is for someone to design the test protocol [22:09] we need someone to sit down and *list* what needs testing [22:09] I can sponsor a server, if needed. [22:09] once we have done that, we can identify test resources [22:09] * etherbob has joined #twiki_release [22:10] Someone requested that we discussed a specific bug [22:10] * PeterThoeny_ has quit IRC (Read error: 110 (Connection timed out)) [22:10] Item5765: Unresolved license issue (TrueType fonts may not be redistributed) [22:10] That was Markus. [22:10] That would be me, yes. :) [22:10] what is your question Markus? [22:10] that's an extension bug; or is the reporter sying they don;t have rights to change it? [22:11] some files needs to be purged from svn... [22:11] purged? [22:11] Is the problem that some files are in the history of SVN? [22:11] No question; the problem is that the repository contains original TrueType fonts which are not to be redistributed. [22:11] Yes, exactly. [22:12] hmmm. Not sure we can remove histories without rebuilding the entire repository [22:12] yep, in the history [22:12] I removed them for the current revision, but anyone who is able to locate the Changeset link or retrieve older revisions, gets those files. [22:12] Does SVN puke if you change the rights (not readable/extractable)? This would affect all checkouts of older revisions, but would be a fast solution if it works. [22:13] yes, you have to rebuild the entire repository [22:13] Sven wrote it would take "bloody long" to clean it up properly. [22:13] right [22:13] * etherbob has quit IRC (Client Quit) [22:13] and it would be high risk [22:13] what is the risk here? Legal action? [22:13] I guess, yes. [22:13] Could be, yes. [22:13] Will someone really come after us for having some files deep in a subversion? [22:14] if you have a good lawyer, no problems ;) [22:14] I would not loose sleep over this. [22:14] we would have to show we had taken "all reasonable steps" [22:14] which IMHO means "removed the latest" [22:14] Well, I only know of one project which distributes those files, and that's the html2ps project. Since we archived those with the ToPdfAddOn, we are no 2. [22:14] Well, we made it into the history books. ;) [22:15] Hm... SVN uses symbolic links, does it? What if we just destroy those files in the meantime (overwriting them with 0's)? [22:15] Is there a CRC check somewhere (i.e., does SVN detect this manipulation)? [22:15] please test this on a copy first. :) [22:15] uebera||: http://subversion.tigris.org/faq.html#removal [22:15] Naturally we have to remove them from the plugin. Which we did. I would not say we distribute anything. You have to hack deep to get these files. [22:16] CDot: I know, that's the correct way I mentioned. [22:16] "Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies." [22:17] yes. Way too risky. And noone will ever chase us for this. [22:17] Yes, that's why it's so messy. If we cannot change the access rights on disc or change the contents on command line (dd if=/dev/random of=...) or the like, I don't see an easy solution. [22:18] can we just corrupt them slightly? [22:18] We should delete Item5765. :) [22:18] given that these files are accessible to anyone who checks out a subversion repository, I'm afraid i think markus is right and we have to erase them completely. [22:18] so they are not the same [22:18] hacking it isn't going to work. That's higher risk than deleting them [22:18] * MartinCleaver nods [22:18] what we really need is a (1) list of all the files and (2) list of the versions they were checked in at [22:19] What about removing all attributes (files not readable any more)? [22:19] All files are listed in the Changeset --> http://develop.twiki.org/trac/changeset/17009 [22:19] uebera||: then I think we have to use the official method. [22:20] ok, that needs to be actioned against one of the people with login access to d.t.o [22:21] which is Sven, Kenneth, Peter and me, I think [22:22] markus, can you update the bug to WaitingFor against that group of people please? [22:22] Ok. [22:22] thx [22:22] Any Other Business? [22:22] These are the same fonts any Windows machine has on the disk. Noone is going to chase an open source project because we accidently put some files on a subversion server and deleted them again. [22:23] * OliverKrueger nods [22:23] Lavr_: A risk has been identified; I prefer not to put the project at risk if it is avoidable. [22:23] Fair enough. [22:23] mind you, they would only sue someone with money [22:23] which means they would go after Peter....... [22:24] He has money??? ;-) [22:24] ok, last chance for an AOB [22:24] no? [22:24] I did not prepare any feature proposals. [22:24] I wanted to focus on 4.2.1 [22:25] OK, good. Are you happy? [22:25] AndreU!!! [22:25] jepp? [22:25] and all. Is it time to ask people to do translations? Or are there docu things that need updates? [22:25] translations will be updated [22:26] and ppl will be asked if needed of course [22:26] It is my feeling that the remaining open bugs will not change strings. So we should start translations then. [22:26] ok, who will anounce a string freeze or is it me? [22:26] Are there any web two dot oh apps out there to do po-file translations via web? [22:26] Anyone disagrees? [22:27] Oliver, never saw any good one [22:27] I can declare the string freeze on ML and in minutes. [22:27] ok [22:27] Lavr_: ok. :) [22:28] Lavr_: do you want to set a release date? [22:29] I am leaving for a vacation on the 6th of August. It would be great to release just before. [22:29] Sounds as good as any other day. [22:29] I know the build contrib still produces zips. I tested that only a week ago. [22:29] So then a release would be in the weekend 2-3 August. [22:30] Well, you're the one who has to be satisfied [22:30] Let us make that the release date. Otherwise I may be able to release from Canada. [22:30] and if you think that's the date, that's good enough for me. [22:30] You going back to YUL, Lavr_ ? [22:31] OK, last chance to any more AOB? [22:31] AOB stands for ? [22:31] Any Other Business [22:31] OK, great. Meeting is closed. many thanks, all! [22:31] Yes. I am going to New York on the 6th and on to YUL 4 days later [22:32] Yes. THANKS all. It was great so many of you could come today. [22:32] see u [22:32] * MartinCleaver waves [22:32] bye guys [22:32] * EugenMayer has left #twiki_release ("Kopete 0.12.7 : http://kopete.kde.org") [22:32] * MartinCleaver has left #twiki_release [22:32] * CDot has left #twiki_release [22:33] bye ;)