Session Start: Mon Jul 02 22:00:05 2007 Session Ident: #twiki_release [22:00] * Now talking in #twiki_release [22:00] * Topic is 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x07x02' [22:00] * Set by CDot on Mon Jul 02 19:59:04 [22:00] hi all [22:00] Hello [22:03] hi kenneth! [22:03] hi arthur, crawford, sven [22:03] sven here in person? [22:03] ish :) [22:03] holla all [22:03] * ktwilight has joined #twiki_release [22:04] hello [22:04] just got home from a walk, and have to make dinner, but :) [22:04] will be here for a bit, got a 6am flight to catch tomorrow, so... [22:04] greetings, earthlings! [22:05] ktwilight: going somewhere nice? [22:05] hm, not sure, haven't been there before. it's barcelona [22:05] just a day trip, got a meetin' :) [22:05] it's nice :-) [22:05] ah [22:05] well, too bad i won't be spending there long enough :( [22:06] it's always good to have a look, so you know [22:06] will keep in mind for next time [22:06] ktwilight, presume you'll see rome next month :) [22:06] haha nah [22:06] no business for me there [22:07] humpf :) [22:07] all roads lead to rome [22:07] all roads lead to twiki :-) [22:07] so, what are we waiting for? 8 minutes already.... [22:07] ah! i remember! twiki community thing isn't it in rome [22:07] not so many folks today [22:08] crawford, you are right, lets get started [22:08] i volunteer to play the facilitator role [22:08] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x07x02 [22:09] who is taking the moinutes? [22:09] I can do that [22:09] nothing to do with "moin" [22:09] ok, great [22:09] proposed agenda: [22:09] # 1. Action Item Review [22:09] # 2. Review Urgent Bugs [22:09] # 3. Coordinate TWiki Release 4.2 [22:09] anything to add? [22:09] only two days in rome, oh my. [22:09] don't mind me :) [22:10] if not, lets start [22:10] actually, i'd like to brainstorm quickly on the rome meetup [22:10] * CarloS has joined #twiki_release [22:10] * CarloS is now known as CarloS_ [22:11] * CarloS_ is now known as CarloS [22:11] lets take that as 4. Rome community meetup [22:11] hi carlo, welcome here! [22:11] * CarloS has quit IRC (Client Quit) [22:11] heh [22:11] ---+ 1. Action Item Review [22:11] * CarloS has joined #twiki_release [22:11] # All need to follow up on bugs waiting for feedback [22:12] i guess mixed success [22:12] A disappointing lack of success [22:12] a few were cleared early on [22:12] but many more have just stagnated [22:12] * CarloS has quit IRC (Remote closed the connection) [22:12] Lavr: did you ever chase the guilty parties? [22:13] No. I get too many negative reactions chasing anyone [22:13] It is not fun to be on this project anymore [22:13] i send a few, for example richard on i18n [22:14] * CarloSch has joined #twiki_release [22:14] kenneth: is this due to code freeze during bug fixing period? [22:15] No. Personal attacks [22:15] * CarloSch has quit IRC (Client Quit) [22:15] I am fed up with them [22:15] :/ [22:15] * CarloSch has joined #twiki_release [22:15] * CarloSch is now known as CarloSchulz [22:15] yes, i understand [22:15] we should address this [22:16] how about defining a NoFlamePolicy in codev? [22:16] i imagine we all are, unfortuantly it requires everyone to be less agressive in how they write. not just the person that is currently making you angry. [22:17] I cannot argue anything that you have to do with Sven without it being perceived as an insult. [22:17] and for me it appears mirrored :) [22:18] i i didn't have features and code to complete, i would have walked away already [22:19] ok, for this meeting lets accnowledge the issue, and take this as an action item to work something out until next meeting [22:19] no, that is ignoring the issue, Peter. [22:19] i suggest to define a no flame policy that states a conflict resolution path [22:19] we should not be in the position that two members of the dev team can wind eachother up [22:19] i think we are all in the same boat [22:19] policies will not resolve this [22:19] differences can be worked out [22:20] we need more proactive input from other people [22:20] otherwise disagreements just spiral out of control [22:20] IMHO - others may disagree [22:20] good point [22:21] i see two things: [22:21] 1. define a no flame policy with conflict resolution [22:21] 2. work on individual issues as a team [22:21] If you all notice quite many that used to contribute to the core have disappeared more or less the past 3 months [22:21] yes [22:21] we probably all have our own theories why that is [22:22] harald stopped contributing because he does not need the 4.2 features [22:22] do you think the arguments have driven them away? [22:22] we are drifting off agenda, but this is a good discussion, so lets continue [22:22] Argument do not help the situation. I take that part of the blame. But that can not be the only reason [22:23] agreed [22:23] personally i think the arguments between me an Lavr have very little impact [22:24] well, they appear to have an impact on Kenneth, which is not good [22:24] it does not help, but most people are intellegent to realise that he and i have similar personalities, and it feeds off each other [22:24] it sure impacts me [22:24] kenneth is less active than usual, so there is a big impact [22:24] but I tend to see argument as one aspect of a healthy development process [22:25] like i said, i'm only still here cos i have things i need to finish [22:25] otherwise, i'd go take a few months to work on other things to find the fun again [22:25] I have two problems on my mind as possible reasons. [22:25] 1. The scope of 4.2 has been more narrow than usual [22:26] mmm, i don't agree - the scope is/was wide open [22:26] no-one contributed even before the 4.2 decision [22:26] 2. The development of certain features have been a very long process where developers of "other features" have either felt not able to contribute or if we are lucky - just wait [22:26] Lavr: what is 2. ? [22:27] y, twiki::cache put me off for a month or two for that reason too - that one i agree is hard [22:27] I am not referring to a single individual here [22:27] not sure I understand that fully [22:27] when there are complex sounding big sounding changes happening [22:27] Well. Arthur has made quite large skin related refactorings. [22:27] less experienced people hold off [22:27] cos its hard to know what changes hit you [22:28] CDot has has also been rearranging quite a lot. [22:28] true; but what features were proposed by those less experienced people? [22:28] And Sven's mapping stuff has been a large task too. [22:28] if the feature proposals had been more, I probably wouldn;t have refactored as much [22:28] its a real chicken and egg issue [22:29] BTW the refactorings were mainly in the infrastructure, and not in the core code [22:29] though, during the periods when there was not much development by the experienced twiki coders [22:29] veyr little was proposed too [22:29] its like saying there are lots of bugs [22:29] when you measure it, its not quite as true as it shounds [22:29] My point is - and I do not have THE answer - is that we need to think how we - in future - address the BIG changes without leaving MAIN in a state that is hard for an occational bug fixer to work on [22:29] sounds [22:29] i counted 6 open engine bugs [22:30] all others were waiting on feedback [22:30] Lavr: well, that's why branch development was initiated; but we found that didn;t work either [22:30] related to kenneth's 2., we have an imbalance where we are in code freeze (stopping smaller contributions) and large code changes ongoing for user mapping and skins [22:31] that re not finished [22:31] i should point out - I liked the develop branch [22:31] no, i don;t think we do [22:31] code freeze? i thought it was a feature freeze??? [22:31] I think the vast bulk of the code changes are complete [22:31] and have been for some time [22:31] s/code/feature/ [22:31] sorry [22:31] all but 3 of the 839 unit tests pass [22:32] the plugins are in a bit of a state, granted [22:32] but apart from that, we are in very good shape for bugfixers wanting to contribute [22:32] i would be interesting to see what proportion of time the bugs system was unavailable - due to bugs in the code [22:33] yes now we are finally getting there. But May-June I went into "let us wait till they are finished" mode. [22:33] And I am sure many others did too. Also testeres [22:33] testers [22:33] ok, accepted [22:33] I did see that [22:33] but i think that is over now [22:33] yes, that was a cause for the delay (no finger pointing, just stating fact) [22:34] meaning, for next time we need to go on a train model, the train leaves the station with or without a feature that is ready [22:34] e.g. only features that are "done" will get on the release train [22:34] one wonderful thing about the 'train' model [22:34] anyway, would it help to make a noise about the code being pretty stable now? [22:34] is it will encourage branches [22:34] this helps speed up the release [22:35] I think it is OK if in periods we all agree that 2-3 developers does a major code-rewrite. If planned and announced it does not have to be a negative thing [22:35] ie, I'll build my code in a Sven branch, and let someone else merge it into mainline [22:35] Then the rest can give certain plugins and docs some TLC [22:35] that was the case for the last 6 months [22:36] there was nothing stopping plugins&docs being changed, running on 4.1.2 even [22:36] yes, major code-refactors are ok during normal dev periods, but not at feature freeze [22:36] that was the case mostly, even with my work [22:36] peter, there have been no major refactorings since the feature freeze. [22:37] all the work has been related to exploring and fixing the many obscure corner cases [22:37] and making sure eerything works as expected [22:37] From feature freeze till now took a bit longer than I think most expected. [22:38] feature freeze was Monday 28 May 2007, we had large code changes since then [22:38] feature freeze != code freeze [22:38] If we had known and planned around it the exact same scenario could have been received positively. [22:38] most of the code changes I have made in that period have been bug fixes [22:38] I guess this is a lesson learned. [22:38] I have not conciosuly added *any* new features since the freeze [22:39] though I have fixed more than a few broken features [22:39] looking it from the small contributor side: it would have been ok to defer the feature freeze by 4 weeks until other large features were ready [22:39] namely user mapping and skin [22:40] No. I do not have the feeling the problem was breaking the feature freeze. [22:40] I don;t think the feature freeze was mistimed, personally [22:40] the reason i am stating this is for next time, to be more vigilent what is on the relese train [22:40] the problems for me have been (1) very few people fixing bugs and (2) even fewer testing, in any sense [22:41] i feel that there are a number fo smaller features that could have made it into 4.2 based on the delay we had [22:41] Yes. But when you have the impression that bugs you will find is because code is not yet finished - then you - by natural reaction - Wait! [22:41] very likely - with the massive assumption that someone would code them, and write unit tests for them [22:41] Lavr: a fair point; though there are many other bugs.... [22:42] I suspect i added about 700unit tests in the last month [22:42] you added quite a few, yes [22:42] i'm not sure that any refactoring in the code base would prevent others from soing similar [22:42] doing [22:42] yes, sven and crawford, among others, have been writing a lot of test case [22:42] But it has been difficult to test when very basic functions were unstable. Like pattern skin, authentication, table plugin just to name a few [22:42] and thats one of the major things that slowed my development [22:43] "cases" [22:43] as i found there were a lot fewer tests than i expected [22:43] ok, can we draw a line under this? [22:43] I think we agree we should all work harder/faster [22:43] ok, we all stated things [22:43] lets look forward [22:43] and lets continue [22:43] # All have to focus on resolving bugs and writing unit tests. Forget the enhancements. We are on feature freeze. [22:43] it is not in itself bad that it takes time to code things. We just need to get better at planning and communicating it in future releases [22:44] yes [22:44] Lavr: a fair point. [22:44] (above was second action item) [22:44] no need to dvelve into it [22:44] As I said before, to the best of my knowledge neither Sven nor I have added any features [22:44] ---+ 2. Review Urgent Bugs [22:45] I haven;;t been as diligent watching the skin changes, but I'm sure arthur took the message on board as well [22:45] kenneth, do you want to drive the urgent item review? [22:45] OK. I can do that [22:46] moment [22:46] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/AllOutStandingItems?class=.*&=&sortcol=3;table=1;up=1#sorted_table [22:46] Item4308 getListOfWebs() and webExists() disagree [22:47] (I am starting with the waiting for feedback in the hope we can move them along) [22:47] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4308 [22:47] * sven__ is now known as SvenDowideit [22:48] what is the issue here? [22:48] difference in spec for the 2 func functions? [22:48] From the report the two functions getListOfWebs() and webExists() does not return consistant results [22:49] but no evidence of that; hence "waiting for feedback" [22:49] So I assume you tried and did not see the issue [22:49] better to presume not enough information to try [22:50] Yes. Michael need to provide a list of which webs he had and what he had in mailnotify [22:50] which is the most common problem with bug reports, not enough detail to not be stabbing in the dark :( [22:50] Lavr: no, I tend to focus on the reports that have enough info to reproduce the problem [22:50] Michael normally is pretty good in his reports so we need to ping him. [22:51] I have done; but he's been busy [22:51] we do not need to solve the issue here [22:51] just the actions to take [22:51] Next http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4295 [22:51] TWiki crash in user mapping code [22:52] Richard seems to know what his next step is [22:52] next http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3400 [22:53] Also a clear ownership from Steffen that he needs to look at is when he returns from whatever [22:53] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item1985 [22:53] That one seems more in limbo [22:54] there are a bunch of RSS issues, that really need a regular RSS reader to look into [22:54] I don;t use RSS myself, so the motivation isn;t strong [22:54] and then to add unit tests [22:55] right; there are no unit tests for RSS, anywhere [22:55] as that'll stop it ever happening again [22:55] so it's too easy to break [22:56] As far as I can read from the bug item it is still the spec that is being discussed and Steffen seems to need feedback [22:56] "Is it correct spec that the original search string is translated to HTML entities, but the output from $formfield is not?" [22:56] from what i've heard, the feed is not even valid xml atm [22:57] I have the feeling that Steffen will like to work on this and just needs feedback to this direct question about $formfield [22:57] hmm, i had the assumtion that rss feeds just deliver plain text all the time [22:57] that is what $summary does [22:58] I guess the issue is that $formfield may not in a search result used in an RSS topic [22:58] this looks like an enhancement [22:58] rss feeds nowadays send escaped html [22:59] a $formfield returns whatever is in the formfield [22:59] a $formfield(foo, plain) [22:59] that was a feature i put into 4.0 [22:59] or the like [22:59] and i think cairo too [22:59] e.g. deliver form field spripped of special chars [22:59] the RSS skin ought to make sure that's escaped, i think [22:59] anyway, it needs someone with the motivation to make RSS work sit down and go through it [23:00] yes [23:00] as it's my assumption that many other search results are able to break it [23:00] But Steffen's question was about the output of $formfield in a SEARCH independent on RSS or not [23:00] I assume he want that feedback before he alters the behavour [23:01] if i understand correctly, formfield values in rss is a feature that was not supported so far [23:01] Lavr: I'll take a closer look and comment, if you think it would help [23:01] e.g. not an urgent bug [23:01] e.g. a feature enhancement [23:01] mmm, if you look at the rss feeds [23:01] i'm told they are invalid [23:01] and broken [23:01] standard rss feed only uses $summary [23:01] i think either ktwilight or QBFreak reported it on irc the other day [23:01] if that is brken it needs to be fixed [23:02] ok, so seperate issue, sorry [23:02] Two more urgent waiting for... [23:02] pretty much a simple -ish bug someone newer could handle - and write tests for [23:02] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4296 [23:02] Configure crashes due to unset variable (Webserver_uid) [23:03] Waiting for Richard but he is the last that gave input. [23:03] I asked him to re-test on Ubunta [23:03] no feedback on that yet [23:04] Maybe you should ping him [23:04] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2032 is next [23:05] Again waiting for Richard who was last to give input on the item so who is it really waiting for? [23:06] Again, I think Richard is the only person likely to close that [23:06] isn't i8n actually waiting for an active developer to drive it? [23:06] I'm certainly not in a position to comment. [23:07] and without, reality may need to be faced - that it should be pulled out of the core somehow, and made an optional contrib [23:07] Richard is talking about a patch. I have the feeling he is waiting for someone to pick it up - or reject it - or discuss it [23:08] not perhaps a desirable reality, but one that should be considered seriously :( [23:08] No, I already applied the patch for him [23:08] I suspect pulling it out of the core would be very difficult [23:08] OK. yes I see there are two checkins. [23:08] as the contrib would have to make multiple core patches :-( [23:09] shows how dangerous it is to have that code without a developer activly looking after it [23:09] guess so :-( [23:09] I would not say that I18N as such is an isolated feature. [23:09] I'm surprised no-one from Japan, China or Russia has picked it up [23:10] looks like we should to recruit a i18n developer [23:10] indeed [23:10] yes. We need someone with a very different char set background to become active [23:11] Maybe we should put an "add" on the twiki.org front page. [23:11] or israel; hebrew reads right-left, which is even more exciting ;-) [23:11] no promise, but let me ask some of my contacts in japan and china [23:11] PeterThoeny: "wear the t-shirt" when you are in Beijing [23:11] :-) [23:12] OK on to the urgent bugs with no owner [23:12] Do we discuss Build contrib bugs? [23:12] not usually [23:12] OK [23:12] they are more placeholders for me than anything else [23:12] I will put my name in [23:13] any urgent bugs of default extensions we should discuss? [23:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3668 [23:15] no idea [23:15] sounds like a bug, though [23:15] might also be how its been for years ? [23:15] Very special case [23:15] dunno; I'll try it on Cairo [23:16] ah no wait - he's including a URL [23:16] so it's behaving as per spec [23:17] It is for sure not an urgent one. [23:17] sweet :) add unit test :} [23:17] i blame CDot - i now am back to doing TDD [23:17] no, I'm wrong. It needs someone to do a proper analysis [23:17] and generate a testcase [23:17] Can we lower to normal? [23:18] I would say so, yes [23:18] but only after analysis [23:18] strong observation - anyone that makes a reasonable failing test case that worked on 4.1.2, has a very good chance of having it fixed by us. [23:18] very true [23:18] Yes. Normal does not mean ignore. It just means - normal. [23:18] anyone that creates a bug, runs a good chance of needing to fix it too [23:19] At least there is a work around for the user in this case. [23:19] yep [23:19] move on [23:19] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3652 [23:19] I18N: Attachments to topic with umlauts in it are lost [23:20] Since last time Richard has added a patch [23:20] i18n again [23:20] 24 june [23:20] does Richard's patch contain a unit test? [23:20] He wrote: "Updated patch is attached - would like to check this in but I can't test this currently due to crash bugs in other bits of TWiki... See other bug reports made today, but particularly Item4295 which is blocking me." [23:20] ah, if he added tests as well, I'd be more confident about closing those reports :-( [23:20] hell, has anyone cared enought about i8n to make any unit tests at all? [23:20] he was using develop.twiki.org at the time [23:21] he has since been redirected [23:22] Added a reminder for him on the bug [23:22] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4282 [23:22] TwistyPlugin generates invalid html [23:22] *ping* ArthurClemens [23:22] hi [23:23] have to look into that [23:23] personally I don;t think it's urgent [23:23] BTW it only happens with prefix and [23:23] suffix [23:23] as there is no indication of any browser it fails on [23:24] no, just a red sign on validator.w3c [23:24] i'd say this is normal, not urgent [23:24] Micha can solve it by himself it this is urgent enough for him [23:25] next [23:25] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4048 [23:25] template refactoring is still not done as far as I hoped [23:25] * wnorris has joined #twiki_release [23:25] EditTablePlugin: Password in URL params after template login [23:26] hi will! [23:26] hello from madrid :D [23:26] ah, flamenco country [23:26] Hi Will - The 4048 really seems serious [23:26] wnorris: Madrid? That's not in Holland..... :-/ [23:27] * wnorris looks [23:27] going back to AMS wed 6:30 [23:27] yes, and this needs to be fixed in the core imo [23:27] wnorris, are you going to be in rome?? [23:28] it will be tough [23:28] i want to [23:28] (obviously!) [23:28] *probably* not, but still looking for a way [23:29] you can doit :) [23:29] Lavr: that's one I started to look into; I think it may not be unique to EditTablePlugin [23:29] No looks more like the filtering out belong to core [23:30] right [23:30] * wnorris is now known as wbniv [23:30] i think the login code should filter out any username/password on redirect [23:30] that will take care of any plugin that uses url params [23:31] not just e.t.p. [23:31] * wbniv changes topic to 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x07x02' [23:31] best done by someone familiar with login code [23:31] I believe it *does* filter; it may be a CGI version issue. [23:32] anyway, it needs further analysis. [23:32] so won;t be done until late next week, at the earliest. [23:33] Next http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4081 [23:33] Broken Links to Topics and Subwebs [23:33] time check: +90min [23:33] Doc issue. But is it clear what to doc? [23:34] lets try to finish by +120min [23:34] (5 more items) [23:35] yes, I think it is clear [23:35] Steffen understands, anyway [23:35] clear doc item [23:35] not urgent [23:35] I guess he wanted input on "which docs" [23:36] textformattingrules is one [23:36] wikiword another [23:36] i am not aware of any other doc that describes linking [23:37] Let us stick to those two to close the bug [23:37] * wnorris has joined #twiki_release [23:37] actually textformattingrules includes anoter topic [23:37] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3714 more I18N [23:38] Item3652 is broken for character sets other than ISO-8859-1 and EBCDIC. [23:38] No news from Richard on that one [23:38]