Session Start: Mon Jun 18 22:06:20 2007 Session Ident: #twiki_release [22:06] * Now talking in #twiki_release [22:06] * Topic is 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x06x04' [22:06] * Set by CDot on Mon Jun 04 22:07:17 [22:06] Peter just dropped a minuted ago [22:06] Good evening [22:06] speaking of the.... ;) [22:06] Hi Kenneth [22:06] I had to kick the wife off the computer [22:06] poor her [22:07] off your skype! [22:07] Yes. She was on skype with her mom [22:07] No multitasking? :) [22:07] well, one gets to know one's colleagues [22:07] They talk every day at 21:30 [22:07] Normally for 20 minutes [22:08] every day? that's dedication [22:08] or addiction [22:08] Make them feel close. Her mom is in Montreal [22:08] they are probably discussing all Kenneth's flaws [22:08] yes. They laugh all the time. [22:08] And I have no clue because it is all in Quebec French [22:09] heh [22:09] I hear Kenneth blabla kenneth HaHA hA! [22:09] psychological torture [22:09] Mother in law in Montreal. Safe distance :-) [22:10] so, do we have an agenda? [22:10] * CDot changes topic to 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x06x18' [22:10] Not sure. Still waiting for t.o [22:10] It is not responding at all at the moment [22:10] we can run through the release blockers [22:10] That was my plan anyway [22:11] action review item 1: Sven/Crawford - Create accounts with sudo access for d.t.o when up again for Kenneth and Arthur. Ask Richard if he needs one. [22:11] Sven made the account for me so I assume this is all done [22:11] I used it today for debugging [22:12] did you try loggin in? [22:12] I didn't get a notice [22:13] I talked to Sven, too. If I get him right, I will get an account soon, too. [22:13] I see klavrsen, but no aclemens [22:13] oh wait, there is an aclemens [22:13] t.o is running speedy_backend. Someone activated the speedy cgi on that again [22:14] ArthurClemens: I can reset you password if you want [22:14] what's the ssh url? [22:14] develop.twiki.org [22:14] aclemens@develop.twiki.org [22:15] I tried that [22:15] but I get: The RSA host key for develop.twiki.org has changed, [22:15] and the key for the according IP address 64.38.10.58 [22:16] that's the right IP address [22:17] I don't have the password [22:17] I am logged into twiki.org. I cannot sudo so my account is worth ZERO. [22:17] Trying to kill the wild processes. Not allowed [22:17] * PeterThoeny has joined #twiki_release [22:17] Lavr__: # User privilege specification [22:17] root ALL=(ALL) ALL [22:17] aclemens,klavrsen,peter,cdot,sven ALL=(ALL) ALL [22:17] so you *can* sudo [22:18] on d.t.o anyway [22:18] On develop.twiki.org yes. Not on twiki.org. [22:18] I used sudo on d.t.o today to view logs [22:18] sorry, i am late :-( [22:19] hi all :-) [22:19] Hi Peter [22:19] Hi Peter. twiki.org is practically dead. And I cannot sudo. [22:19] oh! [22:20] load is 3.05, very high [22:20] lets see who the culprit is... [22:21] Do we have sth like iptraf on the box? [22:22] someone has changed my old password [22:22] sven is doing the server admin [22:22] sven_, around? [22:23] btw, where are we with the meeting? [22:23] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x06x18 [22:23] We passed action item [22:23] ok [22:23] who is facilitating? [22:24] Arthur started I believe ;-) [22:24] So we can check this off [22:25] ok, please continue :-) [22:25] I will contact sven about my pwd [22:25] 4. Coordinate TWiki Release 4.2 [22:26] Desired outcome: Decide on tentative dates for string freeze and other dates; identify and assign action items [22:26] Beta release: 17 Jun 2007 [22:26] we didn't make it [22:26] Not ready for beta at all. [22:26] how many open bugs do we have? [22:27] anything before we jump into the release blockers? [22:27] and how far is sven with his impl [22:27] ? [22:27] of what [22:27] ? [22:27] I assume you mean the new user mapping work etc [22:27] The user mapping stuff. [22:28] yes [22:28] we will have to ask him [22:28] Sven is maintaining a todo list. But I am not sure if he is at the end because it still grows as new issues come up. Not a critique. Just a recognision that it is a big task [22:28] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker counts 21 items [22:28] but that includes plugins as well [22:29] I believe he has an issue working out how to manage groups [22:29] The release blocker also count non core non default plugin items. But most are core/default plugin related [22:29] Item4249 RegistrationApprovals is not a web [22:29] That is a new bug that suddenly showed up [22:30] But I agree with the accessment that best fix is to move it out of data [22:30] That's not urgent, IMHO [22:30] small & contained item [22:30] CDot not urgent???? [22:30] anyway, more to the point: [22:30] not urgent, but good to have for 4.2 [22:30] The bug is that you see the RegistrationApprovals as a web in the web list. That is urgent [22:30] how are we going to get (1) documentation and (2) I18N addressed? [22:31] because it shows up in the left menu [22:31] here is what counted as a web: [22:31] up the cairo: existing WebHome topic [22:31] twiki 4.x: existing WebPreferences topic [22:31] it looks CDot provided a fix in the topic [22:31] so a logical fix is the test for the webprefs topic [22:31] a better fix is to move everything non-web stuff out of the data dir [22:32] No, the logical fix is to make it not a web [22:32] snap [22:32] it's a trivial fix, IMHO. Just waiting for someone to do it. [22:32] We used to have a spec that defined what a directory had to contain to be a web. This seems to be broken. That is the real bug. Rest is enhancement [22:32] I thought Micha was on the case. [22:32] Lavr__: no. [22:32] no, i think a logical fix is to allow only webs in the data dir. that allows us to remoive extra checks in the code, which improves the performance [22:33] The spec of "what is a web" is very clear [22:33] So what is a web? [22:33] a directory that contains WebPreferences is a web, according to the current store impl [22:33] again, this is new spec in twiki 4 [22:33] up to cairo it was the webhome topic [22:34] But RegistrationApprovals does not contain WebPreferences. So. Do we need to fix that bug then? [22:34] read the bug topic [22:34] it is quite clear [22:34] let's not spend any more time on this [22:34] i think it is a no brainer to move reg.app. out of data, and to remove the webprefs test [22:34] is RegistrationApprovals not in a contrib yet? [22:34] No it is not clear. it does not suggest fixing that a directory without WebPreferences is not a web [22:34] if you remove the webprefs test, you have to fix the other bugs that it was introduced to fix [22:35] and in what way is that a "bug"? [22:35] no need to spend more cycles if we agree to move it into work area [22:35] any voice against this? [22:36] I am very confused now. What is the spec? [22:36] What does it take for a directory to be a web? [22:36] because right now - a directory of any kind is a web [22:36] no [22:36] twiki: existing webpreferences topic makes it a web [22:36] that is for twiki 4 [22:36] for webExists to pass, it must contain WebPreferences [22:37] in Cairo, *any* directory was a web [22:37] In my MAIN I see RegistrationApprovals in the left bar [22:37] which was a bug reported and fixed over a year ago [22:37] So there is a bug in MAIN now. [22:37] yes [22:37] unless someone added WebPreferences to RegistrationApprovals [22:38] anyone against moving reg.approval to working area? [22:38] I don;t know, i haven't wated cycles investigating it [22:38] So we have an urgent bug then. We cannot ship with a visible RegistrationApprovals [22:38] if you say so [22:38] You do not agree? [22:39] You think it is OK that 4.2 has RegistrationApprovals in the left bar? [22:39] so the bug appears to be that it shows up as a web while it does not have WebPreferences. To move it to pub is a different issue. [22:39] YES exactly [22:39] please, can we move on? we have accepted this is an urgent bug; do we need to solve it here? [22:40] who signs up to investigate the first line? [22:40] moving to work area means also removing the restiction of webprefs in web [22:40] no, it doesn't. That's an entirely different issue. [22:40] depends on what people put in data [22:40] Yes. People may have put plugin dirs in data. Who know. [22:41] but I think we are using up much time for a relatively small item [22:41] we have identified the issues now [22:41] As long as we agree it is urgent we can move on and we have [22:42] next: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4250 [22:42] Pipe symbol (i.e. in SEARCH) brakes Form Definition Table [22:42] CDot's proposal: use \ as a general escape in form definitions [22:43] Does not sound like an urgent bug unless this is something new that breaks old searches [22:43] i do not think this is an urgent bug [22:43] it isn't [22:43] Frank marked it as urgent. [22:43] I think we can downgrade this to normal [22:43] ok [22:43] agreed [22:43] ok [22:43] Doing it [22:44] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4204 [22:44] Difficult to figure out how to register as Admin user (was impossible) [22:44] doc work to do? [22:45] "The SUDO login must return to TWikiAdminGroup topic and not to Main as I also described in the original bug item text." [22:45] it still contains a bug that makes it difficult. [22:45] When you sudo login from the TWikiAdminGroup page you end up on WebHome¨ [22:45] The redirect should get you back to TWikiAdminGroup [22:45] Remember this is a newbie user trying to become admin. [22:46] is that a blocker? [22:46] yes. [22:46] How to become an admin is one of the most frequent questions we have with installation [22:46] we need to keep this as urgent to spur sven on. No point in labouring it, though. [22:46] Lavr__: agree that sven must finish the job? [22:47] is sven_ here? [22:47] no [22:47] Other that are familiar with redirect can give him a hand. [22:47] it must be the same redirect that we know from normal template login [22:47] sudo is a template as well [22:48] I guess it won't be too difficult [22:48] next? [22:48] If you can give Sven a hand I am sure he will be thankful. [22:48] The TablePlugin bug is on my plate [22:48] Yes. My favorite bug [22:49] I have had to hack the css on our Twiki to get the vertical bars back. But then I cannot turn them off. [22:49] So I would like it to stay urgent [22:49] I know the item [22:49] yes, I am going to work at it [22:49] but lots of template stuff got me diverted [22:49] Thanks Arthur. [22:50] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4217 [22:50] PreferencesPlugin is not working any longer - either failing to save or barfing [22:50] yes. That plugin has been totally lost. it does not work at all any longer. [22:50] And since it is in the default plugins we need to fix it. OR throw it out. [22:50] it just needs some tlc [22:51] is "renderFieldForEdit" in Func? [22:51] first preference: fix plugin [22:51] second pref: remove plugin, so that it does not block release [22:51] otherwise it will need hacks again [22:52] or different code [22:52] I can have a look at it [22:52] I have fixed plugins before [22:53] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2032 [22:53] another UTF monster [22:53] over my head [22:54] anyone to help out? [22:54] yes. How do we get all these I18M bugs addressed. One thing is a couple of Danish letters. But when we go to different characters sets totally then I am totally lost in the character set hell. [22:54] ah, twiki 4 does encoding of some chars in form fields [22:54] I think the question is - who can we try to mobilize who has a personal or business interest in it? [22:55] it needs someone who has a business interest, I think [22:55] if this happens to be a 3nd or 3rd byte of an utf-8 char it will break it [22:55] it affects many people - there are frequent questions - but no-one wants to help :-( [22:56] we can try to lobby richard donkin [22:56] richard pops in every so often, but just doesn't have the bandwidth to fix it properly [22:56] perhaps he knows someone else even [22:56] we cannot rely on him [22:56] There was a guy with a Russian name Alexander I think that gave some patches. [22:58] can we send out a couple of emails to Alexander and other foreigners to ask for coding support? [22:58] i sent an e-mail to richard asking for help [22:58] If you do not have a server and a browser and OS etc setup for some advanced character set then it is darn difficult to work on. I do not even have Danish OS. [22:58] last name of alexander? [22:59] I cannot remember but he reported some of the bugs marked i18n I think. [22:59] I have a vague memory of it. [22:59] but Chinese, Japanese and Korean people will [22:59] it could also have been on Codev. [22:59] Did we have any asian reports with proposed fixes? [23:00] people that propose fixes must have some knowledge in the area [23:00] my idea [23:01] Lavr__: do you volunteer to collect names? [23:01] OK. I will try and search [23:01] and approach them? [23:01] yes [23:02] :-) [23:02] the only alexander with i18n in support web is AlexanderSorokin [23:02] http://twiki.org/cgi-bin/view/Support/FailedAuthenticationWithApache2OnWinNT [23:02] is that the one? [23:03] Looking [23:03] When t.o eventually answers [23:03] Lavr__: thanks [23:03] Item3714 is I18N as well [23:04] it doesn't load [23:04] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3400 first [23:04] Peter - that that may be the one I remember [23:04] TWiki.ResetPassword fails with "cannot find user" if not authenticated and user not in Main.TWikiUsers [23:05] wait for sven to finish before re-testing [23:05] ok, pass [23:05] (note for Arthur - the Attachment Twisty is broken again) [23:06] Lavr__: I am working on TwistyPlugin [23:06] and I updated TwistyContrib in the meantime [23:06] OK [23:06] untill it was meeting time [23:06] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3714 now loads [23:07] waiting for Richard as well [23:07] 3714 sounds like Richard almost knows the fix [23:08] I hope he can add some more feedback [23:09] skipping Item4118 [23:09] as it is UserMapping work [23:09] i send rochard another mail asking for help on 3714 [23:09] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item3963 [23:09] s/rochard/richard/ [23:09] NatEditContrib: Messes up the twisty in Edit Settings [23:10] Not a default plugin [23:10] (did not make it) [23:10] did we decide to ship the contrib? [23:10] it was not ready for feature freeze There are still many open issues with it [23:10] a shame for the work Micha has put into it [23:11] that happens [23:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4048 [23:11] EditTablePlugin: Password in URL params after template login [23:12] This one if true is a real stinker [23:12] looks like post params are converted to get params [23:12] I actually wonder why it never got priority. [23:13] There is a suggested fix in it [23:13] the fix looks simple [23:13] but perhaps it should only use the params it needs [23:14] and filter all other parameters out [23:14] ah, but the filter only takes out alpha chars [23:14] passwords might contain any type of chars [23:15] Ye [23:15] s [23:15] yes, I think it should filter out parameter keys and values the plugin does not need [23:15] there might be any form value from a plugin [23:16] like from SendEmailPlugin [23:17] is this the path to take? [23:17] other plugins might have a similar issue [23:18] better to do the filtering in the core? [23:18] Sound like a generic issue yes. [23:18] we can't if they use query_string() [23:19] or we must put it in Func and let plugin authors use that function [23:19] i mean, to filter it out in template login before doing the redirect [23:19] The real issue is not any parameter but username and password when authenticating with TemplateLogin as I understand [23:19] ah [23:20] yes, but it might be any form data if you end up in a different topic [23:20] and that is easy using parameter redirectto [23:20] they are easy to filter in the login before passing on to the redirect URL [23:21] in fact, I thought they *were* filtered [23:21] Yes. That is what I was thinking [23:22] I might fill out an email form, end up in a different topic with a table, and see the "you're fired!" in the sort links [23:22] ArthurClemens: no, they'd remove you network access before they fired you ;-) [23:22] :-))) [23:23] ok, no harm done then... [23:23] I think if we can just filter out the authentication bit we are fine [23:24] find the code that processes the login parameter, and simply delete it from the Vars hash, or call the CGI delete_param method [23:24] that should stop it being passed on [23:25] ok. we need to rewrite the bug title with this info [23:25] couple of I18N items left [23:26] There are also a couple of doc items where I have questions [23:26] we have passed doc items marked as urgent [23:26] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4063 [23:27] Seems like it is stalled on making a decision [23:28] It is a little more than a doc issue. it is more a UI issue [23:28] sorry, my ICR client is slow as hell [23:29] there are two issues [23:29] 1. pwd reset must not be authenticated [23:29] 2. where to redirect to on failed auth [23:29] i 1. solved? [23:30] s/i/is/ [23:30] Yes. And the 2 is sort of unfinished discussion on the bug item [23:32] what is a "Get lost" page? [23:32] i recall that we had a security advisory on redirect to a static html page on failed auth instead of a twiki script [23:33] ArthurClemens: a page that says "I don;t know who you are; get lost!" [23:33] hmm [23:34] ah, here it is: http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2006-6071 [23:34] so it is safer to redirect to a static html page [23:34] that html page may contain a link to registration [23:35] and other links we agree on [23:35] Is it possible to make a static html that always have valid links to registration and reset password? [23:35] I would have thought so, yes [23:36] The answer to that is NO. If you changed the name of TWiki web. But in most cases people don't [23:37] no, you misunderstand; you can create static reset and register pages [23:37] So I would suggest a static page - very anonymous - with links to registration and to reset password. [23:37] and have them direct to the register and resetpasswd scripts [23:38] pragmatic solution: do not add links, but add description to "go back in browser" and do this or that [23:38] if we add links we'd need to have an installer script that fixes the links at install time [23:39] why? We don;t fix the links in the TWiki front page [23:39] Today we have this in the default apache conf. ErrorDocument 401 /twiki/bin/view/TWiki/TWikiRegistration [23:40] Which people also have to alter if their URL does not start with /twiki [23:41] scripturlpath can be anything, not just /twiki/bin [23:41] Yes. I am just saying that today you manually have to fix this in the apache config also. [23:42] We can put in - commented out two alternatives. ResetPassword and a static dumb error topic [23:42] i'd go for the pragmatic solution of not adding live links in the error doc [23:42] Which we put in the root [23:43] I meant static dumb error html page [23:43] with no links [23:44] can someone just do it, please? [23:44] OK. I can make a proposal and check it in. [23:44] And make the ApacheConfigGenerator so it can handle all 3 [23:45] great, thanks [23:45] cool, thanks kenneth! [23:45] The other one I have a question about... [23:45] flooding [23:45] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2108 [23:45] Documenting how to become an admin user. I am having a hard time [23:45] understanding certain things myself and Crawford also had a question on twiki-dev [23:45] Never saw an answer to the question. What are exactly the 3 settings in configure [23:45] {AdminUserWikiName}, {AdminUserLogin}, and {SuperAdminGroup} [23:45] and how do we imagine our newbie installer will understand this [23:46] I newbie user will think that setting these is the way to become admin. [23:46] But that is not correct. [23:47] it does look confusing [23:47] I wish it was correct but the community has agreed on the sudo login solution. So now it is totally confusing when we also have these 3 settings [23:48] ArthurClemens, is right [23:48] it is not correct [23:49] i do not understand yet the admin changes... [23:49] sven_: welcome [23:49] and its currently 1) not finished, 2) a pulling together of some legacies that still need tying together [23:50] So what is your plan with these? [23:50] {AdminUserLogin} was added for symetry with efaultUserLogin [23:51] {defaultuserLogin} and to be consistent with what the user would see if they set {AllowLoginName} [23:51] but its currently disabled, as there were some issues with the flow on in the unit tests [23:51] {SuperAdminGroup} is a group ONLY now [23:52] ie much less confusing, and alot more EXPERT [23:52] So is the AdminUserLogin and AdminUserWikiName the names you get when you sudo login? [23:52] my plan is to focus on what i seem to be good at, and what is most urgent - getting the code to work [23:52] consolidating the docco and the settings, comes after that [23:53] yep [23:53] Maybe renaming them will help a great deal. [23:53] yes, once the code is done it will help [23:53] right now, it will just cause me to waste another half day [23:54] Do these have to be configurable in the first place? [23:54] don't know, don't think it matters until the code tells us [23:54] The code tells us??? [23:54] y [23:55] I must admit that I prefer requirements first, then design, then code, then test [23:55] i suspect the admin login is not needed at all, but i can't be sure yet [23:55]