Session Start: Mon Jan 07 22:01:45 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/ReleaseBlockers' [22:01] * Set by CDot on Mon Oct 08 10:19:21 [22:02] hi arthur, koen, kenneth, sven and nonzero [22:02] hi [22:02] * CDot has joined #twiki_release [22:02] nonZero: could you please introduce yourself? [22:02] greetings! HNY everyone! [22:02] hi crawford [22:02] Hi everyone [22:02] cheers you too [22:03] a fun, successful and healthy year to all of you! [22:03] Hi All! great job guys - i'll just be listening today - I'm in a real phone confernce now too :-) [22:03] * PeterThoeny is now on a mac, all new tools to learn [22:03] PeterThoeny: Leopard? [22:04] did you try the "wiki" yet? [22:04] nonZero: what is your wikiname on twiki.org? [22:04] yes dot [22:04] the Leopard wiki? [22:04] aye [22:04] "cdot" [22:04] :-) [22:04] PeterThoney: UdiOron [22:04] thanks [22:05] * CDot forgives PeterThoeny; Mac keys are all in the wrong places [22:05] yes, i am constantly hitting the wrong buttons, habits die hard [22:05] CDot today is the first day I had Wysiwyg in a full working day of production and I have had to spend hours helping people that edited a topic and ended up with something that looks like this. [22:05] http://www.lavrsen.dk/twiki/bin/view/Motion/NetcamMjpegStreamDumps [22:05] shall we get started? [22:06] I have not raised a bug item on it yet because I do not know what to write in it. [22:06] release meeing minutes at http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2008x01x07 [22:07] i can facilitate unless someone feels like [22:07] And I am on the minutes [22:07] cool [22:08] proposed agenda items: [22:08] Lavr: that's odd. Looks like an edit was started on an old version, triggering a merge. [22:08] # 1. Review Urgent Bugs [22:08] # 2. Coordinate TWiki Release 4.2 [22:09] In none of the cases were two editing at the same time. [22:09] anything to add to the agenda? [22:09] if not, lets start with: [22:09] ---++ 1. Review Urgent Bugs [22:10] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlockers [22:11] oops, here is the correct link: [22:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker [22:11] * PeterThoeny changes topic to 'http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker' [22:11] Item5185 User mapping testcase is giving a false positive [22:12] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5185 [22:12] I think the fix is good for this [22:12] I have been running the testcases all day, with various code revs, and it's holding up. [22:13] Could do with some confirmation from Harald/Kenneth though [22:13] I managed to run with that code for about an hour before I left work. It looked OK. [22:13] good [22:14] Except the bug recorded as 5118. The code changes did not fix that [22:14] Item5191 distribution is missing the file templates/oopsalertsnohtml.tmpl [22:14] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5191 [22:14] I gave Colas the source, and asked him to check it in. Not sure if he did yet.... [22:15] Colas tested but did not understand that you expected him to check it in [22:15] i suggest to action without asking colas to checkin [22:16] my repositories are in a state of flux, so I'm not going to volunteer to do that right now [22:16] can someone else please pick up that action? [22:16] I can do that [22:16] ta [22:16] thanks kenneth! [22:16] Item4946 urlDecode() not working for characters represented by Unicode code points [22:17] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4946 [22:17] * CDot is interested to hear other opinions on this [22:19] It is difficult to have an oppinion on something I hardly know about. [22:19] harald and hideyo satted that they tested it [22:19] "stated" [22:20] although a bit of a risk, i think it is worth while accepting the patch [22:20] then you favour disabling the testcase? [22:20] Last statements from Hidey seems to say there is still a problem. [22:21] live with testcase failures until test cases fixed [22:21] ? [22:21] we can't [22:21] a segfault stops the test run [22:21] we have to decide to disable the testcase [22:21] ah [22:22] pinions? [22:22] The problem here is not if we disable a bloody test case. Can you write chinese i TWiki or not? That is the question. [22:22] I *think* (I can't be sure) that this will affect only non-Latin-1 users [22:22] so it will only bite chinese, russians, urdu etc [22:24] we cannot release 4.2 without supporting the asian market [22:24] well, it's hard to make a statement one way or the other about that [22:24] or we can make a decision to release 4.2.0 without support, and release within 4 weeks 4.2.1 with support [22:24] the testcase that is being presented is an artificial one [22:25] I cannot see how it can arise in normal usage [22:25] without more thorough testing, it is hard to be sure [22:25] and no-one is testing non latin-1 char sets [22:26] so; we can wait for a "go" message from a non latin-1 tester (if one can be found) [22:26] or; we can release with the current "best efforts" status quo [22:26] we have not sen that the patch causes problems so why not accept it? [22:27] Last statement was "In any case, meanwhile, I'll try modifying the patch to avoid segfault." [22:27] right. The segfault does no happen without the patch. [22:27] So the patch is not good as I understand it [22:27] I'm not so sure. [22:28] The segfault happens because a string containing %ACTION is fed to the urlDecode [22:28] urlDecode interprets %AC as a unicode char [22:28] and segfaults [22:28] however [22:28] %ACTION should never be fed to urlDecode in normal usage [22:28] only %37ACTION [22:29] I cannot recreate a "real" case where a broken string is passed to urlDecode [22:29] therefore, I *think* the patch is OK [22:29] we cannot expect hideyo to provide a fix for the segfault in a timely manner [22:29] but without more testing, I cannot be sure. [22:30] he is very busy at vp level [22:30] it is said of open source "you get out what you put in" [22:31] since no-one is prepared to support testing 16-bit chars in a systematic way..... [22:31] then they cannot expect support. [22:32] we have to live with the non commitment for the time being [22:32] but that should not prevent us from accepting best efforts [22:32] s/accepting/preventing/ [22:32] s/accepting/not accepting/ [22:32] ok, then let's accept the patch and disable the testcase. [22:33] * PeterThoeny 's brain is not working [22:33] any voices against? [22:33] I really can't say [22:34] ok, so let's do it [22:34] Disregarding this specific test cases it must be possible to find an asian person that can try and type some chinese and tell us if it works [22:34] must it? [22:35] shall we ask richard donkin? [22:35] If it does not work then at least we need to know and be able to annouce that wysiwyg only works in latin chars [22:36] i will ask richard to test [22:36] who is checking in the patch? [22:37] Lavr: this is nothing to do with wysiwyg; that was Hideyo's assumption, but it's wrong [22:37] it's a generic problem with any URL params that are urlDecode'd [22:37] Then it is even worse. [22:38] yes, but I don't believe it's a real problem [22:38] I haven't seen a testcase [22:39] * CDot stamps his foot and holds his breath until someone produces a testcase [22:41] who is checking in the patch and disables the test case for now? [22:42] If "the Patch" is the 28 Nov one then I can check it in. But I cannot test it because I do not know how to. [22:42] ok, no commitment now, let's move on [22:42] ok, that is fine [22:43] thanks! [22:43] i will ask richard after you have done the checkin [22:43] Item5179 Quotation marks are translated to entities destroying TWiki Applications [22:43] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5179 [22:44] I have been running with the Wysiwyg in production for a few days now but because of much more severe problems I cannot say is this problem is gone. [22:44] But I think there is a good chance THIS problem is solved. [22:45] Keep it waiting for me for a few more days [22:46] Lavr: I need you to isolate the "much more severe problems", as what you showed me has never been reported before [22:46] of course, if may be because no-one is testing :-( [22:47] I have seen what I showed you 4-5 times today at Motorola and now once on my Motion TWiki. And I have had the Wysiwyg enabled since Friday at Motorola and since Sunday at the Motion TWiki. [22:48] very strange; yet it has never been reported before. Please try to isolate it. [22:49] I think it is some race that happens when people work real time. When I looked at the log I saw two POSTs from same IP about 15 seconds apart. [22:49] One with a 200 result and one with a 302 [22:50] I have the feeling people are using the pickaxe and saving. All topics that failed were looooong topics. [22:51] hmmm [22:51] well, please try to isolate it and generate a report, and I will look into it [22:51] I will be away next week, so the sooner the better [22:51] I have made a place holder report. [22:51] Item5218: Wysiwyg editing often creates a bogus conflict and merge that destroys topic [22:52] Will post my Motion topic file there with Apache log. [22:52] ok, I will look forward to some more detail. [22:52] # Item5163 SpreadSheetPlugin causes table to misrender an empty row [22:53] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5163 [22:53] i just tested on twiki 4.1 and cairo [22:53] same bug [22:53] meaning old bug that was discovered now [22:53] i suggest to reprioritize as normal [22:54] Is it only this simple test case that fails?? [22:54] it probably won't occur that often [22:54] dunno [22:54] I have only seen it happen on the empty row [22:55] that fact that it survived for many years is an indication that it does not happen often :-) [22:55] OK with me to "normalize" it [22:55] ok [22:55] Item5213 SCRIPTNAME not defined when using Sun One Web Server [22:56] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5213 [22:57] no idea; no way to test [22:57] needs someone to follow up with the reporter [22:57] i vaguely recall that we had a similar issue many years back and fixed it [22:57] He suggests a fix. There is a patch and everything. So maybe by confirming it does not break Apache that patch can be accepted. [22:57] right [22:58] shame there are no standards for env vars set by web servers :-( [22:59] should be easy enough to check if the var he proposes is set; just look at configure [23:00] s this an urgent bug? [23:01] i do not think that this is a release blocker since sun one server is an esoteric case [23:01] me neither [23:02] ok [23:02] better to give enough time for this one and add the fix in 4.2.1 [23:02] Item5217 EditTablePlugin does unwanted merging of cells because it no longer leaves space in empty cell [23:02] Arthur seems to have attacked this one [23:02] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5217 [23:02] yes, I am looking at it [23:02] but it is hard to find the cause [23:03] This one is really serious. I had to revert to a December 17 version and spent an hour to repair topics today [23:03] there is a lot of trimming going on [23:03] As far as I remember EditTablePlugin was never able to handle merged cells. it would always un-merge them by adding at least ONE space between | | [23:04] and I fixed that [23:04] Well. Now it removes that one space when you edit the table again and leaves the cells merged instead [23:04] I noticed that [23:04] so I am looking at it [23:05] It seems to be when you hit edit the space is eaten. If you type a space it saves correctly. It requires that you edit and save again to get the problem [23:05] The test case in the bug report is the result AFTER I edited twice. It started with a table with a single space in the empty cells [23:05] as a workaround you could add a space at save time if there is none, lesser evil [23:06] let's wait until I have tried some more [23:06] i meant to add a space in the plugin code [23:06] yes, agreed [23:06] Item5118 Difference from 4.1.2 - 4.2: Apache loginname no longer works with access control lists [23:07] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5118 [23:07] Sven could not reproduce. I added a detailed description how to today this afternoon. [23:07] The only case that fails is when a topic or group uses the login name instead of Wikiname and the person trying to access is registered. [23:08] So with a TWiki where people only uses Wikinames for access control there is no problem. [23:08] And with a TWiki where noone registeres and all uses login only there is no problem either [23:09] But I still think it should be fixed. It worked well in Cairo and in 4.1.2 [23:09] did you re-test since Sven fixed the false positives? [23:09] Yes. I tested after applying those fixes. [23:09] the testcases were failing for AllowLoginName=1 [23:09] i agree with chris' comment that this was a feature in 4.1.2 (for flexibility of auth) [23:09] moin [23:09] orning sven [23:10] "morning" [23:10] I tried to repro it using login names of registered users [23:10] Moin Sven [23:10] and it worked for me [23:10] hi sven [23:10] I've not read your update, but I presume the problem is setup specific [23:10] hey Sven; you're up early! [23:11] only for a mo, will be leaving to walk pam to work soon :) [23:11] Sven. I put many details. Take a look. If you still cannot reproduce I will add more. [23:11] possibly related to user mapping in twikiusers topic [23:11] oh, pwdmanage=none [23:12] that'd do it :( [23:12] It is obvious that in 4.2.0 TWiki sees you either as c12179 or KennethLavrsen. Not both. In 4.1.2 it seems it would accept one or the other. [23:12] hmmm. That seems to cause quite a few problems (pwdmanage=none, I mean). [23:12] es, that is probably the cause [23:12] "yes" [23:12] CDot, its a bear [23:13] and Lavr and harald keep finding more undoccoed marvels [23:13] that's what they're not paid to do! [23:13] ;-) [23:14] i tested using a 'normal' setup ;p [23:14] Item4551 translation work for TWiki 4.2 [23:14] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4551 [23:14] http://twiki.org/cgi-bin/view/Codev/TWikiTranslationStatus [23:15] what is fi? Suomi? [23:15] yes i presume [23:16] translations needing work: gb, cs, es, fi, jp, nl, pl, ru, uk [23:16] uk??? that is that? [23:16] color vs colour? [23:16] uk - Ukranian [23:16] ah [23:16] gb - Britich English [23:17] I thought we were in good shape for that, myself.... [23:17] IMHO gb is a "nop" [23:18] so, missing translations are a release blocker, right? [23:19] are they? Depends on the release manager, i reckon [23:19] I'd say, if we are missing Ukranian, release anyway [23:19] es is used a lot and it is at 76% [23:19] if we are missing Spanish, then that's more important [23:21] Is the es file updated on SVN so the untranslated strings are there? [23:21] dunno, sorry, I haven't been watching [23:22] there are 158 registered twiki.org users from .pl [23:23] t would be nice to get some visibility on commitment of translation [23:25] agreed [23:27] I guess it is more lack of knowledge of how to than lack of people that would do it. Not even I am sure how to make an updated .po file. [23:29] You just need to translated what's there [23:29] and update what is not [23:29] agreed there is something you need to know [23:29] like # fuzzy [23:30] but it is really a lot of work [23:31] like 2 evenings non stop for one translation [23:33] * PeterThoeny_ has joined #twiki_release [23:37] seems we have stalled...... [23:37] did we run out of agenda? [23:37] Yes. I think we are done with the bug items. The only one left us upgrade guide and that is still on my list based on my RC testing [23:37] and the upgrade work I had to do [23:38] OK. Well, IMHO we should release, but i know you feel differently with your merge problem [23:38] I am surprised I haven't had that report from anywhere else. [23:38] Yes. I plan to take the Wysiwyg out of production tomorrow morning again. We cannot live with that. [23:39] Remember that I have reported this from two completely different TWiki installations. [23:39] it is already in daily use in a lot of sites [23:39] I'm wondering if there is a plugin conflict, unique to you [23:39] No have reported because very few are testing this in a real browser and with real topics. [23:40] * PeterThoeny has quit IRC (Read error: 110 (Connection timed out)) [23:40] remeber, it works in 4.1.2 as well. It has been downloaded by a lot of people [23:40] of course they may not be using it; but I'd be surprised if such a major problem escaped notice [23:41] Peter is having network (notwork) problems [23:41] he is typing, but we are not seeing his typing [23:42] * PeterThoeny__ has joined #twiki_release [23:42] * PeterThoeny__ is now known as PeterThoeny [23:42] can you see this now? [23:42] Another problem is editing tables. Try and do this in practical on real tables. Try and insert line breaks and remove them again. I have had several users asking how to turn the Wysiwyg off because of this. [23:42] ok, i am back [23:42] sorry, i had a network issue [23:42] Bugs is hanging for me again. I cannot edit or upload again now. [23:43] That is the 3rd time just today [23:43] Which is why I have not reported more bugs. [23:43] I think I have the solution for the edit table bug [23:43] Arthur cool. [23:44] Peter when we get the new servers - we also move develop.twiki.org away from Slowservers right? [23:44] now I need to add a couple of unit tests [23:45] * PeterThoeny has quit IRC (Client Quit) [23:45] Lavr: Bugs is running fine. Must be your old war wound playing up again. [23:45] Can you tell when it is going to rain? >:-) [23:45] * PeterThoeny has joined #twiki_release [23:46] hello world, can you see me now? [23:46] yep [23:46] yes. it is the same bug again and again. All I have to do is to change to another computer on another ADSL line and then I have access again. And it is random if it is one or the other that locks up. Or the one at work. [23:46] ok, sorry, i had a network issue [23:46] And the one at work is a German IP address. [23:46] Lavr: threaen to shoot Steffen unless they fix it [23:46] are we done with the release blockers? [23:47] Motorola's connection in Germany is not TDC. [23:47] yes we are done with release blockers. [23:47] CDot I uploaded the apache log on http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5218. [23:48] As I expected the user had used pickaxe and there is multiple saves seconds apart. [23:48] i have one more item: [23:48] d like to ask ArthurClemens [23:48] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5142 [23:48] universal edit button [23:48] any chance to get it into 4.2? [23:48] should be a small and safe change [23:49] * PeterThoeny was typing and typing until i realized that i talked to myself [23:49] that's the point, it wil take time to test this [23:49] you want to add a feature 2 days before release? [23:49] acn we release in two days with so many blokcers open? [23:49] can we *ever* release? [23:50] ew reprioritized some blockers [23:50] we can reprioritize more if you'd like to release now [23:50] that is a community decision [23:50] * PeterThoeny_ has quit IRC (Read error: 110 (Connection timed out)) [23:51] i missed the part on translation status, but can we release with spanish done 76%? [23:51] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5218 also uploaded a zip with the .txt and .txt,v of the destroyed topic. [23:52] Is this meeting representative of the community? [23:53] if not, what forum *is* representative? [23:53] by definition people intersted in twiki dev participate in this meeting [23:54] have to leave soon [23:54] that's not answering the question [23:54] can this meeting make a release decision or not? [23:54] ultimately the decision of the release manager [23:54] Right now what I would like people to focus on is not to add ANYTHING and not to play with unit tests and other fun programming. What is needed is to open loooong real topics in a browser and edit them and test and test because that is where the remaining bugs are. [23:55] because if the criteria is to clear the existing release blockers, I'm afraid we will *never* release [23:55] as there will always be another one, and then another [23:55] Perhaps we need to set action items with a max date [23:56] for the current blockers [23:56] and frankly, I'm utterly, utterly sick of this [23:56] so either Antonio goes after the translations, or we release with what we have [23:56] I have wroked very hard to try and get this release as far as it has come, and these continual delays and fence sitting is driving me nuts [23:56] I understand [23:56] cdot: please voice for reprioritizing items to normal [23:57] We have always been able to release before and we have always had 1-3 urgent that we deferred. And that is OK with me. Right now the Wysiwyg bug and the EditTable are the only real release blockers. [23:57] plus a few where I check in some code and we are done with those. [23:57] what about spanish translation? [23:58] (just asking) [23:58] Noone here speaks Spanish. it is ONE file that later can be downloaded from a twiki.org page. [23:58] it must come from Spanish speaking contributors, we cannot do it [23:58] But why not ask on the mailing list. I am sure someone comes forward as long as we can give him a clear instruction [23:59] ok, so release also with non finished translations [23:59] fine with me to give that a couple of more days. But we shouldn't wait for 2 more weeks [23:59] agreed [23:59] No we are days away now. Not weeks. Session Time: Tue Jan 08 00:00:00 2008 [00:00] than it is a matter how to proceed [00:00] target date for release? [00:00] we already have one; 9th jan, right? [00:00] we identified urgent bugs, what is the new target date? [00:00] I can add that when I test at Motorola I actually build a release and install it. I do not run a pseudo-install so I am pretty confident that the package is complete. [00:01] Also the Motion TWiki is installed from a TWiki.zip [00:02] Peter, what about all the marketing song and dance? [00:02] shall we go one more time over the blockers for reprioritizing? [00:02] shall we say in a week, on monday 01-14? [00:02] Fine with me. [00:02] Once again, I will be away on the day of a release. This is becoming a tradition. [00:03] from marketing perspective better to release mon-thu, not fri [00:03] And no enhancements. No edit icons. Even small changes creates new bugs. And skin bugs are very visible. [00:03] build on sun, release on mon? [00:03] kenneth, i disagree on the universal edit button [00:04] small and safe change [00:04] but this is your call [00:04] it is not small and safe [00:04] ok, in thsi case deferred [00:04] I did it for TWIKI.NET skin [00:04] and it took me considerable tweaking [00:05] I would have preferred to do the EditTable button the same way [00:05] hmm, did not realize that adding an icon causes much work [00:05] anyway, deferred [00:05] the whole link gets a new size [00:05] yes it has to work with all sizes of windows, all lengths of the breadcrumb, all browsers. [00:05] build release on sun, release on mon ok? [00:06] what do we do with bugs that come up this week? [00:06] Panic [00:06] stick head in sand [00:07] There is always one more bug. And it may cause delay. But let us work on a plan and try to make it and kill the bugs we find if they are severe. [00:07] i'd say it is up to the release manager to decide on prio of bug [00:07] We will have some urgent bugs that get deferred to 4.2.1. We always had a few open when we released. [00:07] can we agree on target: build sun, release mon? [00:08] that's why we have a release manager [00:08] to make this sort of decision [00:08] i need to plan for marketing with michael corbett [00:08] what i need to know is the earliest possible release [00:08] mon 2-14? [00:09] sorry, 01-14? [00:09] Monday the 14th is it. [00:09] I think the critical path is marketing, TBH [00:09] is that a time? [00:09] hey 01-14 is one month earlier than the twiki summit :-) [00:09] ArthurClemens: it's a backwards date [00:09] he means 14/01 [00:10] mean iso 2008-01-14 [00:10] or 2008-01-14 to me unambiguous [00:10] MMVIII I XIV [00:10] ok, are we done with teh meeting? [00:11] Yes [00:11] ok [00:11] thanks all! [00:11] was a long meeting, but it is important to coordinate [00:11] CDot did you look at the log? [00:12] Seems the users click twice when they get impatient. [00:13] [07/Jan/2008:18:04:15 +0100] "POST /twiki/bin/rest/WysiwygPlugin/tml2html [00:13] [07/Jan/2008:18:04:52 +0100] "POST /twiki/bin/rest/WysiwygPlugin/tml2html [00:15] and later he first saves in non Wysiwyg and then in Wysiwyg. he saves between editing in one mode and the other. At least that is what is in the log. [00:15] Somehow this creates a false edit conflict [00:17] hmmmmm. The merge code checks the username of the saver, and ignores a second save if it's the same user [00:17] wouldn't it be safer to disable the submit button once clicked? [00:17] ArthurClemens: the "save" in pickaxe mode is *identical* to a raw edit save [00:18] so if it can happen in pickaxe, it can happen in a plain edit [00:18] The bug to look for is why the merge makes the false conflict. If we solve that the problem is gone. [00:19] It never happened the whole week I ran 4.2.0 at work with Wysiwyg disabled. [00:19] right [00:19] ok, well, please provide as much info as you can [00:19] I may get a chance to look into it on wednesday morning [00:20] I will add as much as I can. I may also send you some private emails with some topics I cannot disclose in public. [00:21] It is also strange that the entire topic is full of ins and del. [00:21] Every line in the topic has a ins and del [00:21] That was also the case at work. [00:23] At work the topic had html that caused also the user interface in the skin - buttons, links etc - to be shown with [00:25] Note the topic of the topic. There is some old garbage that the old Wysiwyg editor left behind. I had to remove this at work because Wysiwyg failed to save if it was there. I did not do that on the Motion TWiki. [00:25] Maybe I have also missed a few at work. [00:25] That I need to check out. [00:26] The garbage is the and [00:28] the problem with the ins and del is simple to explain [00:28] when a user creates a topic using raw edit, they usually put in manual line breaks that TML ignores [00:28] when generating TML from HTML, it is impossible to know where those line breaks were [00:29] so the line breaks all change between a raw, and a WYSIWYG, edit [00:29] that is probably the cause. [00:30] yes. Though it is strange that even inside verbatim areas you see them. [00:30] * ArthurClemens_ has joined #twiki_release [00:31] yeah, thats' odd [00:32] Actually I am wrong. It has avoided the verbatim. [00:33] * CDot wipes his brow [00:33] I have recommended to people that before they edit a large topic they first open it and save it and inspect if all is OK. And then start editing forcing a new revision. To avoid loosing typed data. [00:34] * nonZero has quit IRC (Read error: 110 (Connection timed out)) [00:37] * ArthurClemens has quit IRC (Connection timed out) [00:41] I have made a copy of the topic and I am saving and pickaxing and saving and I do not get the error. Maybe I should try IE. [00:42] unlikely to be browser related [00:43] possibly a result of save-back-save before the first save has completed (guessing) [00:43] I cannot reproduce it. The user has to do something specific for the error to occur. [00:43] * ArthurClemens has joined #twiki_release [00:44] I have a colleague Nicolas that managed to do it 4-5 times in a row while I watched. I need to get him to teach me. [00:52] CDot look at the file I uploaded. The TWiki log. http://develop.twiki.org/~twiki4/pub/Bugs/Item5218/NetcamMjpegStreamDumps_twiki_log.txt [00:53] We can see better the steps he took including some editing without saving and passing by TWikiRegistration a few times. [00:53] Lavr: it's too late, I'm falling off my chair [00:54] I will look tomorrow maybe, wednesday for sure [00:54] Yeah me too. I will follow up with more logs from the work cases tomorrow. [00:54] Good night [00:54] sleep well!