Session Start: Mon Apr 14 21:59:19 2008 Session Ident: #twiki_release [21:59] * Now talking in #twiki_release [21:59] * Topic is ' http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x04x14' [21:59] * Set by ColasNahaboo on Mon Apr 14 21:45:40 [22:00] * PeterThoeny_ has quit IRC (Client Quit) [22:00] * PeterThoeny_ has joined #twiki_release [22:00] Hi there. :) [22:01] Hi Markus [22:01] hi colas, koen, kenneth, sven (up already?), markus! [22:02] * LarsEik has joined #twiki_release [22:02] hi lars [22:02] i sent out the invite with a delay [22:02] hey all [22:03] i was away over the weekend with my family kayaking [22:03] no computer [22:03] just sun and water [22:03] i hope we get enough participation even with the late invite [22:04] * peterthoeny has quit IRC (Success) [22:04] springtime feels good :) [22:06] * ArthurClemens_ has joined #twiki_release [22:06] time check: +05 min; shall we give it some more minutes? [22:06] hi arthur [22:06] hi, I almost forgot [22:07] I am on the meeting minutes. [22:07] i can facilitate [22:08] time: +08 min [22:08] i think we should start [22:08] proposed agenda: [22:08] # 1. Review Urgent Bugs with 4.2.1 scope [22:08] # 2. Feature requests for Georgetown Release [22:09] anything to add to the agenda? [22:09] if not let's start [22:09] ---++ 1. Review Urgent Bugs with 4.2.1 scope [22:09] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker [22:10] * ktwilight_ has joined #twiki_release [22:10] hi all [22:10] hi kwan [22:10] hi peter [22:10] we are just starting with #1 [22:10] ah great [22:10] i just got back :) [22:10] do carry on. [22:10] we have 16 release blockers listed [22:11] there are probably some that just apply to 5.0 [22:11] Yes. Status since last time is that we have had a huge development in the I18N bugs [22:11] positive development [22:12] yes, good that crawford and others pick up on i18n [22:12] Which has created some new urgent bugs but I still see it as a huge development towards getting TWiki to support I18N much much better [22:12] The development is mainly in getting TWiki to run UTF8. [22:12] question is if/what of those should be deferred to after 4.2.1 [22:12] We need more than just me to test this in practical. [22:13] I have found that Searching non-regex is broken and verbatim blocks are broken in UTF8. [22:13] And I am sure there is more to come when testing. [22:14] * harlan has joined #twiki_release [22:14] i can ping hideo imazu to see if he has time to test it [22:14] Some of the current problems affects the OLD iso-8891-1 also [22:14] hi harlan [22:14] howdy [22:14] as long as i know what i'm testing for chinese characters, i'll help out. [22:14] Moving to utf-8 definitively seems out of scope for a 4.x [22:15] thanks kwan! [22:15] There are two levels in this. [22:15] One is to get the CURRENT utf-8 code to work better. [22:15] The other is to move entirely to UTF-8 which is for sure a 5.0 scope feature [22:15] i was just going to ask, is utf8 support in the scope of 4.2.1? [22:15] ah ok, my bad. [22:16] ok, kenneth just answered my question [22:16] am strictly using utf8 on my wiki setup, so far i have no problems. though i didn't try searching and such. but view and edit works fine. [22:16] Currently if you are from China your best chance to use TWiki is UTF-8. [22:17] but i noticed that there are/were some bugs with chinese headers and searches [22:17] ktwilight_: utf-8 issues is with regexpes & searching etc... anything where the number of bytes to represent a char is important [22:17] i see. [22:17] if you search for "." you search for one byte [22:17] Funny thing is that searching works with regex search. But not with query and word search. [22:18] in utf-8 this is not necessarily a character [22:18] You "can" make it work [22:19] if you remember you SEARCH on bytes, not char [22:19] As I just said. Regex search seems to work now. It is the non regex that fails. So I am sure we can make it work in other searches as well [22:19] bu then Lavr's nerd-meter wille xplode :-) [22:19] and of you chop off a string (such as for anchor for toc) you might chop a multi-byte char apart if you are not aware of multi-byte chars [22:19] * MartinCleaver_ has joined #twiki_release [22:19] hi martin [22:19] and this is quite easily solved through a utf8 twiki core? [22:19] * MartinCleaver_ had been hanging out in #twiki_marketing [22:19] we are discussing i18n support using utf8 [22:20] utf8 twiki + utf8 unix +utf8 unix utils (grep, rcs, ...) [22:20] s/through a/through a refactored/ [22:20] i see [22:20] + utf8 perl & libs of course [22:20] and then you have all the user plugins/addons [22:21] and this current situation affects wysiwyg? [22:21] If we are able to normal edit/ wysiwyg edit/ regex search NOW - it seems within reach to get the remaining features working also. [22:21] time check: +20 min [22:21] in any case, we need to fix the new bug on non-regex search not working before we release 4.2.1 [22:22] i hope it isn't alot of work involved for 4.2.1 [22:22] As I remember I could in some cases not search for Danish words in query search in 4.2.0 either. [22:23] OK. let me take some of the other cases. Item5447 and Item5375 are both waiting for feedback from Arthur [22:23] Item5451 is waiting for Michael Daum [22:23] at what time should i ask hideo to help testing (now?), and what features (wysiwyg editor, ...?) [22:24] Item 5443 is waiting for Harald Joerg [22:24] sorry, bbl. [22:24] hideo should run the current TWikiRelease04x02 in UTF8 and try misc applications to see what else is broken. [22:25] for arthur: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5447 and http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5375 [22:25] for michael daum: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5447 [22:25] for harald: http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5443 [22:25] ok, thanks kenenth (on testing question) [22:26] about Item5447: ChangePassword does not store new password [22:26] Next is http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5489 (Tables can no longer be rendered in text area form fields ) [22:26] Yes Arthur first [22:27] Sven proposes to change "changing a password" to authenticated users [22:27] that will have impact on the current flow [22:27] Change password can be authenticated. Reset password cannot. [22:27] as users get an email to change their password following a link [22:28] it would be better if that page is VIEW authenticated then [22:28] if you follow the link you will be asked for a password [22:28] It is very important that we do not fall into the trap again and prevent people that forgot their password from resetting it [22:28] Mmm most systems allow Change only once loggued [22:29] yes, but the current flow from email to the change password must be changed [22:29] But when you CHANGE password you are assumed to know your current [22:29] yes, currently that one is in the mail [22:29] after a reset [22:29] for instance 01223456778 [22:30] Are we talking change or reset now? [22:30] change [22:30] in the password reset e-mail, isn't this simply adding a link to viewauth for the changepassword page instead of view [22:30] ? [22:30] but that is needed after a reset [22:30] well, unless you are not logged in (TWikiGuest) and visit ChangePassword [22:31] Peter seems to be right [22:31] The ChangePassword topic should be modified [22:31] that was my guess too [22:31] to have a * Set DEBYTOPICVIEW = TWikiGuest [22:32] to have a * Set DENYTOPICVIEW = TWikiGuest [22:32] Yes that would force authentication [22:32] yes, and it will work both from email and from browsing [22:32] is there a way to pass the temp password value as url parameter? [22:32] although there is one issue: what if you are under basic auth and a user is already logged in as a twikiguest? [22:32] it seems it is not picked up by the form [22:32] that user will get a view access denied [22:33] because browser is silently sending twikiguest login [22:33] would * Set DENYTOPICVIEW = AnyAccountThatSurelyNobodyHas ? [22:33] work? [22:34] a space [22:35] I think we have the requirements [22:36] we only need to test against basic auth [22:36] I can do it [22:37] time check: +37 min [22:37] OK next [22:37] Item5345: Logging in as admin still redirects to main home [22:37] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5345 [22:38] Who is taking ownership of this? [22:38] I get it always, all the time [22:38] but then I seem the only one with template login [22:39] this one is irritating, but is it a release blocker? [22:39] inbetween [22:39] It harms the new admin. [22:39] Maybe most people firsat declare themselves admin so are not bothered by the bug after install? [22:39] How to become admin is the most common question we get among installers. [22:40] They need this feature to work to become admin in the first place [22:40] You arrive at the TWikiAdminGroup page and want to add yourself as admin. You authenticate. And land somewhere else. [22:41] and without any clear navigation scheme... [22:41] lost for a long time [22:41] yes, that is confusing [22:41] If the "sudo" login does not work from other places than from the TWikiAdminGroup topic I find the priority LOW. [22:43] I wonder if you have some special setup in configure Arthur. [22:43] Reproducing is step one. I must admin I have not tried myself. I use ApacheLogin and has been working mostly on I18N stuff the past weeks [22:44] well, perhaps it can wait until we get a confirmation [22:44] Action: please more of you try and reproduce! [22:44] tried. I can reproduce [22:45] I can try to fix it if it is as simple as it seems [22:45] thanks colas! [22:45] Thanks [22:45] let's assign it to me [22:45] time check: +45 min [22:46] Item5511: Updated attachment gets renamed to attachment name: leads to read errors [22:46] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5511 [22:46] I am not sure if this is a bug [22:47] need more oppinions [22:47] it is unexpected [22:47] why would a new file gets renamed? [22:48] I actually thought this situation resulted in the same as if you had uploaded a new file. Ie leaving the old one untouched [22:48] hmm, this seems new, i recall that in earlier versions if you go to manage and attach a different file name, it retained the name of the newly uploaded file (ignoring that you were at "manage" of the old file) [22:48] yes, you get a new version. but bbc.txt becomes bbc.pdf (version 2) [22:48] Yes Peter that is what I remembered [22:48] so do I [22:49] But I can also see the logic in the new behaviour. [22:50] the new twiki based CMS also caused confusion, because a new uploaded image could not be found [22:50] a cms I created 2 weeks ago [22:50] * sven__ has joined #twiki_release [22:50] I honestly have no oppinion of this. I can see the advantages and disadvantages of both behaviours [22:50] because old.jpg should get replaced by new.jpg, but it was still named old.jpg [22:50] * SvenDowideit__ has joined #twiki_release [22:51] You cannot really REPLACE the file because then you loose the audit trail. [22:51] or the audit trail becomes strange. [22:51] the old behaviour was: just attach a new file [22:51] which is the least confusing [22:52] When was it changed? By who? [22:52] no idea [22:52] i do not know [22:52] probably with code refactoring work on 4.2 release [22:53] who can look into fxing this item? [22:53] first decision - what is the right behaviour? Do people agree? [22:53] I am neutral [22:53] i feel it should be reverted to the original spec [22:54] Colas? [22:54] I dont know [22:54] gmc? [22:55] ktwilight? Lars? martin? Sven? Markus? [22:55] use the comment field to say it was renamed? [22:55] I would rather revert it. [22:56] I think if someone is updating an attachment it should update the attachment [22:56] or [22:56] Ok, by thiinking mor about it The old behavior seems more intuitive [22:56] refuse to take it [22:56] mmm [22:56] or, prompt the user to use the old vs. new name [22:57] no the new once can work also [22:57] i could live with refuse to take it, recommend to a) rename attachment to match old name, b) go to attach a new file [22:57] suppose I manage a "my-work.doc" attachement [22:57] I upload a new version I prepared as my-work-v2.doc [22:58] the intended behavior would be I guess to keep the my-work.doc name [22:58] true, the user would have to rename my-work.doc to my-work-v1.doc locally [22:58] So I guess a warning could be useful [22:58] Yes. There are advantages both with the new and old behaviour. [22:59] the new version works if you expect it this way [22:59] it assumes preknowledge [22:59] agreed that there are use cases for both, question which one is less confusing if you intent to do the opposite of what is implemented [22:59] but you would have to explain it every time to users [23:00] No matter what - some extra guide text on the upload screen would be a good idea. [23:00] I would say the new behaviour is geared towards power users [23:00] It's considerably more work, but could we add a note about the behaviour (on the 'management page') and maybe add a configuration option? [23:00] but noone reads the upload screen texts... [23:00] agreed with arthur [23:00] to 'ass''u'me' is to make an 'ass' out of 'u' and 'me' [23:00] configuration would not work [23:00] we have to remember that the user has clicked on "manage" next to a specific already attached file [23:00] no more configuration, please [23:01] time check: +60 min [23:01] I agree the new one is less normal-user-friendly [23:01] it doesn't need to be [23:01] (clicking manage) [23:01] in my cms the user clicks next to an image to update it [23:01] i still need to call the 'manage' url [23:02] But not on the generic attach link to upload a new file right? [23:02] other use case [23:02] ArthurClemens_: so you want the new behavior in this case? [23:02] quick poll: 1. revert to old behaviour (attach new file), 2. keep as is (rename new file to name of old attachment), 3. reject file, with help text to attach new or rename [23:02] someone uploaded a word doc without extension [23:02] Reject file will probably be the worst thing we can do [23:02] I tried to repair it by downloading it, adding .doc and uploading it again [23:02] but that won't work [23:03] the new file is renamed to the old one without extension [23:03] I we dont agree, just keep it as is for 4.2.1 [23:03] keep behavior changes for 5.0 [23:03] 4. ask [23:03] I would not mind a message if we had a proper alerting system [23:03] leave as is. Change with option 4. in 5.0 [23:03] no more text. TWiki dialog pages are too busy now [23:04] * Sven_Dowideit_ has quit IRC (Read error: 101 (Network is unreachable)) [23:04] * SvenDowideit_ has quit IRC (Read error: 101 (Network is unreachable)) [23:04] and it shouldn't be a js alert [23:05] martin: 4. ask would be a viable option, but out of scope of 4.2.x since we have no good message system [23:05] if we are looking at release 4.2.1, I would revert back to the old behaviour [23:05] No we have to keep things simple for 4.2.1 [23:06] Seems there is a balance towards reverting behavior [23:06] Leave as is [23:06] i am for 1. revert to old behaviour, and am ok with 3. reject upload [23:06] 0 neutral [23:06] 1 [23:06] * MartinCleaver_ votes 2. [23:06] 1 [23:07] More votes? [23:07] 1 keep new [23:07] Colas??? [23:07] is that revert to old? [23:07] 1 (revert) or 2 (keep) ? [23:08] arf, got messed up. keep 4.2 behavior :-) [23:08] 2 [23:08] Colas is with me on this [23:08] * ArthurClemens_ can't believe it [23:08] Maybe we should open the poll to Codev? [23:08] we are sliding into the magical TWiki box [23:08] i feel that we should not burden users with spec changes, hence revert to original behaviour [23:09] Sounds like we have a decision clear as ink. Let us give other chance to comment on the bug item the next days [23:09] ok [23:10] it is these discussions that are the very reason for having release meetings :-) [23:10] Item5514: suppressTWikiSaveValidation and validateTWikiMandatoryFields Javascript errors in IE and Firefox [23:10] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5514 [23:10] Bugs seeks owner. [23:10] I also notice some JS errors now and then that could be same. [23:11] errors that seem harmless but gives alerts in the browser on the status line [23:11] IF statements in templates are very hard [23:12] also because TMPL:P is very picky on quots [23:12] So who will look at it? [23:12] I can have a look [23:12] Great [23:13] OK 2 more [23:13] Item5489: Tables can no longer be rendered in text area form fields [23:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5489 [23:13] I am willing to downgrade this to normal if there is no easy fix [23:14] it seems the problem is that the renderer for tables has to accept codes for new lines as they are used in META instead of real new lines for this to work. [23:14] So I was hoping it was just a minor regex fix in the table renderer code. [23:15] This has worked in previous versions of TWiki. [23:15] 4.1.X to be exact [23:15] Maybe I will take a short look. [23:15] If it is difficult I downgrade to normal. [23:15] (difficult for me) [23:16] Finally we have the old Item5118: Difference from 4.1.2 - 4.2: Apache loginname no longer works with access control lists which is still waiting to be given priority. [23:16] Sven a predicted fix date? [23:16] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5118 [23:18] Sven? [23:18] i asked harlan to look into item5118 [23:18] OK [23:19] harlan - any comments? Do I put you on the bug item and the one working on it? [23:19] AS the one [23:19] ouch - I just got on a business call. [23:19] harlan: please update the bug item topic on the status when you have time [23:20] next? [23:20] will do [23:20] great. This bug has needed attention since december [23:20] That is the list of bugs I wanted to discuss [23:21] Any other bugs people want to discuss or ask questions about? [23:21] if not, let go to the next agenda item [23:21] ---+ 2. Feature requests for Georgetown Release [23:22] http://twiki.org/cgi-bin/view/Codev/TWikiFeatureProposals#ProposalsReadyForReleaseMeeting [23:22] It is a long time ago since anyone have pushed for any of the proposals that have stopped because of concern raised. [23:23] And there are some that I believe are difficult to process because they are part of a greater roadmap type set of features. [23:23] * OliverKrueger has joined #twiki_release [23:23] HelloWorld [23:23] And for those there are actually good progress with discussions in OTHER codev topics. [23:23] So I do not see this as a bad thing. [23:24] But if someone want to push for a decision on any of the other proposals, please ask for it to be taken up at next release meeting. [23:25] hi oliver [23:25] We have TWO proposals ready for meeting both raised by Arthur and both with concern from Sven. [23:25] I am not sure how to progress those two. [23:26] me neither [23:26] on jsquery topic [23:26] I can only understand Svens idea on an abstract level [23:27] and that is not the investment I am going to make [23:27] looking at the amount of work that will take [23:27] http://twiki.org/cgi-bin/view/Codev/MoveToJQuery [23:28] sven__ SvenDowideit__ : on jquery, could you summarize your concern? [23:28] I was aiming for the simple approach: use the js lib winner [23:28] Arthur, Do your proposal would, if implemented, prevent Sven to propose later his grander scheme? [23:29] no, it wouldn't [23:29] (Arthur or Sven of course, BTW) [23:29] So I see no reason to reject Arthur proposal [23:30] and I have used Michael Daum's jquery based twisty plugin [23:30] and I did not see any performance problems [23:30] i would say: let's do one step at a time. arthur's proposal is simple and makes things simpler; we can build on bigger theme later [23:30] agreed [23:32] time check: +91 min [23:32] let's try to wrap up in 15 min [23:32] Reading the proposal I still cannot see where the proposal ended up at. [23:32] it ended with much sand in the engine [23:32] that it we got diverted [23:33] is [23:33] yes, arthur's original proposal is simply to replace behaviour with jquery in the patternskin [23:33] Is your original proposal what you want a decision made on Arthur? [23:34] yes [23:34] OK. Then I will add a voting table on the proposal topic and we will count votes including those people may give at next release meeting. [23:34] What about http://twiki.org/cgi-bin/view/Codev/ProcessAddToHeadAdds [23:36] i have no direct input on this proposal, out of my realm of needs [23:36] It has been long time since I started the topic [23:36] since then others have lead the discussion [23:37] nothing for me to add now [23:38] i am a but concerned on the time it takes to come to a decision, we can build momentum by deciding quickly on proposed features that have a committed developer [23:39] it would be good if the ones that have string oppinions about this project on Codev and feature proposals would show up at these release meetings [23:39] s/string/strong [23:39] yes [23:41] (hi all) [23:41] one action we can take to help drive the timely decision process _is_ to decide on the release meeting with the participants present (that will help also in more participation in release meetings) [23:41] on jquery question i believe we can make a decision now [23:41] Most important is to have a commited developer [23:42] and that the feature do not make irreversible changes [23:42] on process to add to heads we can decide too [23:42] then, we can ge the green light easily [23:42] agreed with colas [23:42] no need to make the process heavier [23:43] If you guys want to vote on the two proposals I will not object. I do not understand the features enought to have an oppinion myself. [23:43] kenneth: do you want to make a quick poll on the jquery feature? [23:44] I do not know the subject, but I have read only very good things about jquery [23:44] Sure: 1 yes (accept original proposal) 2 no (reject) 0 (don't know or don't care). [23:44] 0 [23:44] 1 [23:44] * OliverKrueger just read a quarter of the topics and neither has an oppinion yet. [23:44] 1 [23:44] 1 [23:45] 1 [23:45] 0 [23:46] martin, lars,, harlan, kwan, sven? [23:46] koen? [23:46] hey, I'm sitl on the phone. [23:47] time check: +105 min [23:47] looks like no objection to jquery [23:48] ok [23:48] :-) [23:48] nice [23:48] kenneth, do you want to do a quick poll on add to heads feature, or defer that? [23:49] The last remark on that was that Crawford wanted to change the proposal. [23:49] I think this proposal is *VERY* important for performance, it will help caches immensely [23:49] but I have no clear opinion on the debate on it on how to do it [23:50] Crawford want to make a distinction between topic template and tmpl templates [23:50] for security reasons [23:51] kenneth: quick poll or defer decision? [23:51] so addToHead is not allowed in topic templates [23:51] I think in this case I will add a note thT Crawford should update the proposal - otherwise we will vote for the original proposal in two weeks. [23:51] ok, sounds like a plan [23:52] i think that's it [23:52] actually, more: [23:52] can we decide on a tentative release date for 4.2.1? [23:53] At the moment the bug fixing is going very slowly. [23:53] I do not dare guessing. The actual release work is 4 hours of work for me. [23:53] ok [23:54] quick update on twiki.org servers: [23:54] The release date is purely driven by developer commitment to resolve the urgent bugs AND for everyone to test the current code in both UTF8 and normal old iso--- mode [23:55] marcos della is currently creating the server architecture, should be done by tomorrow [23:55] And when I say test I do not mean edit and save and be happy. You need to try features like all sorts of searching, uploading and downloading files, etc etc [23:55] he is out of town though, will be back on sat [23:55] Lavr_: if i find a way to motivate myself to pick up twiki work again, i might help to slightly speed that process up.. [23:55] i will let you know when servers are ready for ssh login [23:56] thanks koen [23:56] anything else? [23:57] if not let's close the meeting and carry on at #twiki [23:57] no thanks [23:57] thanks all! [23:57] I mean thanks and goodbye [23:57] long meeting today, let's try to limit to 90 min next time [23:57] is it an option to have these meetings earlier? [23:57] * ArthurClemens_ has left #twiki_release [23:58] i find it impossible to stay focussed at 22:00 PM anymore after the long days i make anyways [23:58] bye all [23:58] If people who have English as their language wants to test some I18N then simply use text that contains é è ë ö etc etc. That can be typed also on an English keyboard. [23:58] Those characters will show I18N problems if they are there [23:59] * LarsEik has left #twiki_release ("Leaving") [23:59] Thanks all [23:59] we tried to shift the time a number of times, it is impossible to get a time that works for all Session Time: Tue Apr 15 00:00:00 2008 [00:00] The late hour was chosen to allow Sven to get up not too early. [00:00] OK, I'm off th ephone. [00:00] but he's never here :)