Session Start: Mon May 29 23:02:48 2006 Session Ident: #twiki_edinburgh [23:02] * Now talking in #twiki_edinburgh [23:02] * HaraldJoerg has joined #twiki_edinburgh [23:02] hi all [23:02] Hello [23:02] Back in 2 minutes [23:03] Good evening. [23:03] 'evening [23:03] good evening, good morning, nice day :-) [23:04] * SamHasler changes topic to 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x05x29' [23:05] ready to go? [23:05] here without the trailing dot: http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x05x29 [23:05] where is lynnwood? [23:06] it would be good to have also crawford and will [23:06] what trailing dot? [23:06] after the "x29" [23:06] * SamHasler changes topic to '' [23:06] confuses my irc reader [23:07] Back [23:08] at +8 minutes [23:08] shall we start in a few minutes? [23:08] fine with me [23:08] who is facilitating if lynnwood does not show up? [23:08] who is taking the notes? [23:09] I can take notes [23:09] nice :-) [23:10] thanks lavr. I'll probably leave early tonight, need to be up early tomorrow [23:10] I want an early night too, so I'm only lurking. [23:10] shall i facilitate? [23:11] would be great [23:11] now +12 min [23:12] ok, lets get started [23:12] some key people are missing, we can't decide much on 4.0.3 release [23:12] so lets try to make this meeting short [23:12] anything to add to the agenda? [23:13] nope [23:13] if not lets get started [23:13] the documentation group [23:13] a.k.a. TWikiDocUsers [23:14] let's get to that at the end [23:14] do you want to add this to the agenda? [23:14] ok, lets add it [23:14] y [23:14] please state the desired outcome of the item [23:14] ---+ 1. Review Previous Action Items [23:15] all done basically [23:15] not stated as an a.i., but "Update TWikiReleaseNotes04x00x00.txt with 4.0.3" needs to be done at the time of the release [23:15] I am a little confused on the admin docs. What to do and on which topics. [23:16] I wanted to do something but I was not sure what to do so I did something else. [23:16] i think crawford wanted some clarity where to create new docs for admins [23:16] On the ZzzZ topic it seems not all topics should be altered. [23:17] Example. Should all the VarXXXXX topics have all the headers and footers and comments? [23:17] the result was http://twiki.org/cgi-bin/view/Codev/ProposedInterimDocGuidelines [23:17] these are different things [23:18] the ZzzZ stuff is for the doc team and should be taken offline [23:18] You asked for help on those - that is why I ask [23:18] the "admin doc" stuff is the additional doc not in the release, such as faq, how-to etc [23:19] yes, i can use some help [23:19] i prwfer to take that offline [23:19] i had to prioritize my twiki work [23:19] first prio was twiki.org update to twiki 4 [23:20] back to admin docs, i have not seen much activity [23:20] these are....? [23:20] there are many topics in the codev web that could be refactored and linked to from supplemental docs [23:21] for example the twikion* topics [23:21] for example, stuff that is in the support web that comes up again and again [23:21] such as how to authenticate against ldap [23:21] etc [23:21] why can't they find it in support? [23:22] because there are supposed to be answers... [23:22] I have been working on the apache config topic. Just waited for Twiki4 upgrade because it uses some non-Cairo tags. [23:22] I was planning to add LDAP to it also eventually. [23:22] one perfect example is http://twiki.org/cgi-bin/view/Support/LdapAuthenticationHowTo [23:23] that topic has good instructions but needs some review [23:23] so should be tagged NeedsReview [23:23] and probably bets to create a ldap how-to supplemental doc in the twuki web [23:23] And the next I will look at is the FC5 topic. I have just installed an FC5 on a laptop and will install TWiki on it from scratch and build the topic while I do it. [23:23] that is another good example [23:24] but are people looking in TWiki docs before they go to Support? [23:24] there are many more topics like that that are exxential to admins, but need refactor and linked to from supplemental docs [23:24] and/or new supplemental docs [23:25] the twiki.webhome is the doc entry point [23:25] that topic links to the supplemental docs [23:25] and many distribution doc topic link directly to supplemental doc topics [23:25] such as on installation, plugins, etc [23:26] in my view, the support web is for asking questions, not so much to browse for a solution [23:26] I understand, but will this relieve us from new questions in Support? (I doubt it) [23:26] support web is the raw data for supplemental docs in a concise format [23:26] i think it will help [23:27] example: [23:27] but anyway, _somewhere_ needs to be refactored info, true [23:27] a person installs twiki for the first time [23:27] reads the installationguide in the distro [23:27] follows the link (as recommended) to the supplemental installation docs [23:27] and finds the ldap link [23:27] voila [23:28] we are at +28 min [23:28] YES. It is via clear navigation that we need to guide people. Goal should be 3-4 clicks and you are there. [23:29] exactly [23:29] plus tagged nicely [23:29] anything else on review? [23:29] Could tags be used as sort of a "Keyword Index"? [23:29] can you elaborate? [23:30] If I am looking for something and google returns too many hits - how should I proceed? [23:30] oic, hints for google [23:30] In books I find it helpful to find an index at the end of the book [23:30] that is an intersting idea [23:31] Not only hints for google - hints for people looking for, say "LDAP" on twiki.org [23:31] how about a brainstorming topic in codev on giving google hints? [23:32] just a list of all tags,vertically? [23:32] well, tag cloud is already used [23:32] http://twiki.org/cgi-bin/view/TWiki/InstallingTWiki [23:32] * CDot has joined #twiki_edinburgh [23:33] hi crawford [23:33] well, we've discussed pros and cons of current tags [23:33] hi, sorry late [23:33] regarding "pure" tags and classification [23:33] I am sorry to be negative but people will not find what they need via tags. It is like playing roulette and the hits you get is anything from up2date docs to old Beijing garbage. Navigation and as Harald suggests, a proper index of keywords is proper ways of navigation. Search is the 2nd resport when navigation fails. [23:33] http://twiki.org/cgi-bin/view/Codev/TagMeDiscussions [23:34] So to bring the DocFocusGroup back to life... [23:34] people have their preferred way of finding content: top down navigation, search, tags [23:34] yes, this is a question for the doc team [23:35] shall we stop here and take it later? [23:35] any intermediate point to round off? [23:35] 4.0.3? [23:35] from me, the low hanging fruits are to refactor known admin topics and to link to them from supplemental docs / or to create concise new supplemental docs from them [23:36] any minutes or log so far? [23:36] crawford, we are still on a.i. review [23:36] heh [23:36] closing up [23:36] at +36 min [23:36] I checkpoint save on the way in the minutes [23:36] can i ask for one thing; gardening of invalid/misleading content [23:37] yes, that is a good one [23:37] have seen several support requests where people read wrong doc [23:37] crawford marked some topics at the top as outdated [23:37] which is great [23:37] so this is a (non-smaart) a.i. for all [23:38] besides the admin doc brush up work [23:38] Yes. We have so many people installing Dakar that comes by and talk about where to find setlib.cfg. Something they fould in a "CoolURL" topic. [23:38] ok, move on? [23:38] let moe on [23:38] ---+ 2. TWiki 4.0.3 Release [23:39] what is the current status on build of pre release? [23:39] will is not here [23:39] anybody knows? [23:39] He did a beta. And it installed OK. The only issue with it was plain bugs. [23:40] ok, so build process per se ok then? [23:40] Both Steffen and I installed it and it ran fine. [23:40] nice [23:40] so on to bugs [23:40] where do we stand? [23:41] i mean bug fixing [23:41] shall we go through the release blocker page [23:42] or just mention those we want to talk about? [23:42] http://develop.twiki.org/~develop/cgi-bin/view/Bugs/ReleaseBlocker [23:43] We need the bugs related to registration fixed. If nothing else - go back to 4.0.2 behavour if we cannot fix it now. [23:43] (which means removing ONE line from NewUserTemplate and restoring a fix I did with CDot yesterday which cause other trouble). [23:44] what was the purpose of the fix? [23:45] Before the fix - a feature of showing the hidden email address to the user - did not get copied over from the template [23:45] Now it gets copied but MichaelDaum has trouble elsewhere now so it is not good enough. [23:46] i'd say if we can't fix it in time better to revert to old behaviour, and to provide a patch after 40,03 [23:46] 4.0.3 [23:47] what do you think? [23:47] We could live with it for sure. [23:47] * CDo1 has joined #twiki_edinburgh [23:47] quick question: What is the expected timeframe to release? [23:48] But if a bright guy can figure out how to pad %USERINFO{"%TOPIC%" format="$emails"}% so it does not get expanded from NewUserTemplate to users topic then the old code was OK. [23:49] ok, it seems like we agree to try to fix properly, and if not in time to revert to old behaviour [23:50] I think a fix is easy, ivolves moving 2 lines and reverting the change anyway. [23:50] rafael, lets talk about the release date in a minute [23:50] the other open issue is settings in forms [23:50] who is CDo1? [23:51] http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2302 [23:51] me [23:51] CDot [23:51] ok, thanks [23:52] yea, that is a controversial one [23:52] it is apparently not much used [23:52] but those who did are blocked from upgrading [23:52] I had a quick look to see if it was obvious what Thomas did. It isn't. [23:53] kenneth suggested to provide the functionality as a plugin/contrib [23:54] someone needs to research Thomas' change first. I have a vague memory that he called it a "one liner" [23:54] * PeterThoeny has quit IRC (Read error: 104 (Connection reset by peer)) [23:55] * PeterThoeny has joined #twiki_edinburgh [23:55] I proposed the plug/contrib because it was proposed to put it back and then depreciate it and it would be horrible to introduce something and depreciate it right away. Then better keep it in a contrib. [23:55] (provided it _can_ be done in a plugin./contrib) [23:55] * CDot has quit IRC (Nick collision from services.) [23:55] (sorry, wireless issue) [23:55] * CDo1 is now known as CDot [23:57] the person who removed the feature is elected to create the contrib? :)>- [23:58] anybody helping out on this feature? [23:58] I tried to write (internal Mot mail) to Thomas but no reply. He must be very busy with other stuff. [23:58] you mean thomas weigert? [23:58] Yes [23:58] yep [23:58] i recently exchanged a short e-mail [23:59] he is very busy, no time for twiki a.t.m. [23:59] but willing to answer questions [23:59] (i asked him about upgrading his plugins) Session Time: Tue May 30 00:00:00 2006 [00:00] +60 min [00:01] in other words, this rests on an active community member [00:01] If it is POSSIBLE to do as contrib then it will not hold back 4.0.3 at all. <- out of my skill set natually. [00:01] yes [00:02] crawford, you gut feel, is it possible as contrib? [00:03] gut feel, possible, yes. Sensible, no. [00:03] why not sensible? [00:03] well, it would be a lot of code [00:03] versus the reported one-liner in the core [00:04] oic, more productively done in core [00:04] like I said, someone needs to do the research [00:04] we have a choice [00:04] 1. keep this as a release blocker until investiagted [00:05] We need a coder to investigate it. No owner - no action. [00:05] 2. try as FormsForSettingsContrib, detached from 4.0.3 release [00:05] yes kenneth [00:05] even without owner, 1. or 2.? [00:05] Sorry for a stupid technical question - how could a Contrib get activated for a site needing it? [00:06] (and I'd opt for 2. - don't hold 4.0.3) [00:06] other votes? [00:06] Abandoning users not good [00:07] IF it turns out to be a ONE LINER - then I see no reason to depreciate it afterwards. Only if it becomes a performance monster [00:07] Or break other things [00:07] Nobody gets abandoned. It's just a question whether it should hold the release. [00:07] Yes. Noone said to reject the request [00:08] I have not seen support questions, bug reports, enhancement requests regarding that feature. [00:08] so far one support question [00:08] So maybe we are talking about abandoning exactly 0 users. [00:08] 1 user [00:08] Oh - sorry. [00:08] 1 twiki installation to be accurate [00:08] 1 user == 1 cairo site [00:09] any more votes? [00:10] 1 or 2? [00:11] no more votes [00:11] If we can get a coder to volunteer INVESTIGATING only. Then give him/her 48 hours. [00:11] Otherwise - fall back to 2 [00:11] sensible approach [00:11] everybody ok? [00:11] yep [00:11] and who volunteers? [00:12] the changes appear to be limited to Manage.pm [00:12] SVN range 4285..4289 [00:13] crawford is very busy, who else knows the latest permission code? [00:13] I'll skip [00:13] nothing to do with the permissions code [00:13] purely UI, AFAICT [00:13] Remember - investigate - not implement. How about Harald? [00:13] sorry, not permissions, preferences [00:14] Not within the next week, sorry. [00:14] I will do the investigation [00:14] I have already half done it [00:14] And without a clue about the SVN range where the change came in it is guessing a lot [00:15] cool (h) [00:15] thanks crawford! [00:15] Thanks CC [00:15] any other urgent/required item we should discuss? [00:15] +75 min [00:15] svn diff -r 4284:4289 Manage.pm [00:16] if net, lets move on the proposed release date [00:16] Registration fails if no mail available [00:16] Isn't that quick to fix? [00:16] ok lets discuss reg fail issue [00:16] Or is there a work around? [00:17] no, it's not quick to fix [00:17] i think a simple and flexible solution is a new config flag to tell the system that no e-mail should be sent [00:17] Can you put something intelligent in configure instead of sendmail? [00:17] it's something that needs an intimate understanding of the reg code [00:17] crawford, i do not think that this is a big change [00:17] the problem is the failover in registration [00:18] if you set no confirm to e-mail there is no reason to send email [00:18] (besides notifying the user) [00:18] yes there is [00:18] it is the only way to get a password reset [00:18] AFAIK [00:18] It is the notify email that is the problem. [00:19] If TWiki cannot send the notify email people report that the registration fails - even without verification enabled. [00:19] Password reset is part of bulk registration, isn't it? [00:19] for a site admin who just installs twiki or upgrades the network and has no email it would be good if users still can register [00:19] not being able to reset pwd is not that big issue compared to the first one [00:19] For "normal" registration it isn't absolutely necessary, I'd say. [00:19] then all that is needed is a try..catch around the email send in registration [00:20] no need for a config option [00:20] just let it fail, and catch the failure [00:20] wh not? [00:20] because email is either there, or it isn't [00:20] {MailProgram} could perhaps be set to a work around "program" that does nothing but succeed. [00:20] there are no decisions to be made based on a config option [00:20] as a site admin i want to get notified of e-mail issue (in normal case) [00:21] PeterThoeny: by email? ;-) [00:21] {MailProgram} fails if Net::SMTP is installed, which takes precedence [00:21] no, on screen [00:21] then append it to an admins topic? [00:21] peter, that's the complicated bit [00:21] the bit we want to avoid [00:21] UI changes [00:21] currently if net::smtp is installed (and fails) there is no way to revert to external email [00:22] not automatically, no [00:22] i think the most simple solution is a new config flag [00:22] let the admin dcide [00:22] no ui changes [00:23] so if flag set, the twiki::net always reports "success" [00:23] * CDot gives up [00:23] so all outgoing e-mail looks like ok [00:23] * PeterThoeny listens, how does it affect ui changes? [00:25] go ahead, add your UI option. I just don't think it's worth the effort, and I think we have too many config ioptions already [00:26] do you worry about the ui addition in config, or are there other places? [00:26] no, the problem is total overload of config options [00:26] there are far too many [00:26] and I don;t want to add more [00:27] CDot is right, A failure of Net::SMTP could trigger the fallback in its catch block. [00:27] And the fallback can be - simple log entry? [00:27] Or nothing? [00:28] no, i think in normal case an error should be reported to the screen [00:28] Append a bunch of lines to a topic Main.RegistrationHistory, only readable for TWikiAdminGroup [00:28] That becomes a big feature then. [00:28] And for the user, kindly ask him to try to register next day [00:28] implementation wise [00:28] just in this special case where email is not available it should be possible to supress it (e.g. also for schedulked email outage) [00:28] s/register/login/ [00:29] let's please get our priorities straight here [00:29] * PeterThoeny thinks we would have had to aks twiki.org users to wait for 3 month to register [00:30] +90 min [00:30] is it more important to have a nice recovery from email failure, or settings in forms? [00:30] If verification is OFF and the email is not sent - only the admin really looses anything. [00:30] The user just logs in right away. [00:30] If there is no SMTP - then the admin should know that he does not have one. It is admins that ask for the feature. [00:31] so what can we conclude on this feature? [00:32] If you put a false SMTP server that does not exist and verification is off - I am sure you get registered anyway. I will try that right way. Maybe the issue is not what we think [00:32] comment out the throw in register.pm, replace with a writeWarning. 2 minute to code, 10 mins to test. [00:33] crawford, in normal case i'd prefer to get the error in the browser window [00:33] picture an smtp server that suddenly goes down [00:33] users report those errors if tehy are reported [00:33] I'm sure you would. However that would involve changing the template [00:33] Nope it fails then. [00:34] and translations are already frozen. [00:34] i do not see how that affects the ui [00:34] can you exmplain? [00:35] ok. The way it works right now, if there is an error sending the registration confirmation mail, it throws and exception [00:35] that exception terminates the registration process [00:35] If I put a garbage smpt server the registration fails. the reports are correct. I get a The Page cannot be displayed. No TWiki error page [00:36] if we suppress the exception, then we have a "warning" message in our hand that has to be given to the user somehow [00:36] what is what we want in the normal case (actually with a less imitating error message to the user) [00:37] (reply to your +95 statement) [00:37] i think we agree to not introduce ui changes that afffect tranlsations [00:38] ...so the warning message to the user is always in english [00:38] afaik, the only issue we have at hand is clutter in config (one more flag) [00:39] a nicer error message to the user is a different issue [00:39] (usability question) [00:39] well, the changes could be introduced on the 'thanks' template [00:40] like I said, altogether it's 15 minutes work for a coder [00:40] i'd say let's not make ui changes other than config [00:41] +101 min [00:41] let's stop this discussion here; we are not achieving anything [00:42] ok, lets move on [00:42] release date [00:42] tentative [00:42] can we set one? [00:42] I have some news. IF you clear the {SMTP}{MAILHOST} field in configure and turn off verification - then you can register with no error. [00:42] based on pending blockers and will's availabilit? [00:43] So a fix can be in configure "If you have no SMTP server leave this field blank". [00:43] is that using net::smtp? [00:44] Good question. I have disabled my sendmail (stopped the service). [00:44] My normal SMTP is localhost = sendmail [00:44] I selected the mailo handler based on the setting of MAILHOST, IRRC [00:45] let move on to release date [00:45] is tentative release date open or can we set one? [00:45] depends on getting the release build done [00:46] that appears to be the critical path [00:46] and on fixing blockers [00:46] last note on email: Yes I have Net::SMTP installed. [00:46] Lavr: nice one :-) [00:46] kenneth: good to know, so it is a config text question for net::smtp [00:47] still, a doc solution needs to be found for external mail (if net::smtp is not available) [00:48] it looks like we can't set a tentative release date :-/ [00:49] move on? [00:49] We sort of need Will. [00:49] not without wbniv [00:49] yep [00:49] and coders to fix more blockers [00:49] and he is busy making new friends [00:49] ok, move on: [00:49] ---+ 3. twiki.org upgrade/bugs [00:50] who brought up this? [00:50] can you explain? [00:50] Since when do you need to raise a bug report to edit a TWiki page??? [00:51] When a form is involved, for example [00:51] Or when configuration is in a temporary state [00:51] I thought for that purpose every FooBarTopic has its FooBarTopicDiscussions [00:52] And if not make one. [00:52] a few twiki web topics are locked down [00:52] they already have a *discussion topic [00:52] right. the question was, how to report probems when that is encountered? [00:52] actually _very_ few topics are locked down [00:52] And since testing was requested, sometimes a bug needs to be reported. [00:53] in the past people reported twiki.org issues in the support web [00:53] which is ok i think [00:53] sounds good to me [00:53] Status of configuration at this point? [00:53] and if there is already a *discission topic, report it there [00:54] upgrade roughly done [00:54] important system topics in twiki web need to be updated [00:54] at which point the %TWIKIWEB% will be reset to the normal state [00:55] other pending things: [00:55] - install cron for notify [00:55] - convert user home pages to new format [00:55] * SamHasler has quit IRC (Read error: 104 (Connection reset by peer)) [00:56] * Flenser has joined #twiki_edinburgh [00:56] there are a few other things that can be done as we go [00:56] i am not aware that there are many %TWIKIWEB%.something that point to nirvana [00:56] actually, most point now to the most up to date topic in twiki04 [00:57] So TWIKIWEB shouldn't be used? [00:57] as stated in the codev broadcast message, plese report issues at http://twiki.org/cgi-bin/view/Codev/TWikiOrgUpgradeToTWiki04x00 [00:57] What exact topic is it that you have all this trouble with? I have never heard so much noise for so little. [00:58] * PeterThoeny is wondering too [00:58] I'm just trying to get it clarified. When I write topics, I use %TWIKIWEB% and %MAINWEB% routinely [00:59]