Session Start: Mon Sep 18 22:03:00 2006 Session Ident: #twiki_edinburgh [22:03] * Now talking in #twiki_edinburgh [22:03] hi kwang ern [22:03] :) [22:03] * ArthurClemens has joined #twiki_edinburgh [22:03] * Flenser_ has joined #twiki_edinburgh [22:03] evening [22:03] kwang is a last name is china though [22:03] hi arthur, hi sam [22:03] Hi All [22:03] hi [22:04] kwang is not my last name though [22:04] hi kenneth [22:04] and in chinese, it isn't a last name either [22:04] we have critical mass to start [22:05] who is moderating, who is taking the minutes? [22:05] I guess the rule of habbit make me the minuter [22:05] * Flenser has quit IRC (Nick collision from services.) [22:05] thanks kenneth [22:05] Lavr: You will fail to see any of us objecting [22:06] with rule of habbits, is lynnwood or peter facilitating? [22:06] Personal note: I haven't been involved with TWiki lately as I am working on other projects - not wiki related [22:06] i'm sorry Peter, i can't facilitate as i don't know how long i'll be here. [22:07] will get back when these projects are a bit further [22:07] arthur, we appreciate your tremendous support so far and are looking forward for more in the future! [22:08] ok, i can facilitate unless anyone feels like doing so? [22:08] That would be great [22:09] ok, lets start [22:09] proposed agenda items for today: [22:09] 1. Review Previous Action Items [22:09] 2. Profiling framework Update [22:09] 3. Maintain Hotfixes in SVN [22:09] 4. Vote on Discontinuing use of DEVELOP Branch [22:09] http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x09x18 [22:10] any items to add/remove? [22:10] if not, lets go [22:11] ---+ 1. Review Previous Action Items [22:11] # KennethLavrsen: Send email to Meredith to ask for status on commitment to finish TWikiFns [22:11] Done. No reply received [22:11] ok, all we can do for now on twikifns [22:11] I think we have to write them off, at least until someone has the bandwidth [22:12] yes [22:12] Yes. I think that is clear [22:12] # SamHasler: Draft the changes to the ChangeProposal process in Codev based on the brainstorming info from today [22:12] sorry, not done. [22:12] do you have a timeline in mind? - [22:13] ktwilight is n=ktwiligh@87.66.124.194 * ktwilight [22:13] ktwilight on #twiki_edinburgh #debian #perl #debian-xfce #zope #plone #webappsec #apache #twiki #lamip ##linux #zope3-dev #svk ##luacs [22:13] ktwilight using irc.freenode.net http://freenode.net/ [22:13] ktwilight is identified to services [22:13] ktwilight End of /WHOIS list. - [22:13] I'm not going to have the time until the end of this week [22:13] ok [22:14] so lets keep this action item open [22:14] lets defer "HaraldJoerg: Update the BenchmarkFramework" to later, agenda item 2 [22:14] # RafaelAlvarez : Take a short stab at defining the scope of finishing the work of implementing TWikiFns including docs, t.o. code, testcases etc [22:15] any update from rafael? [22:15] Not that I have seen and with no owner I think it is waste for him to even try [22:16] well, i do not agree that it is waste of time [22:16] * wbniv has joined #twiki_edinburgh [22:16] we need to understand the scope of work, nobody is taking this with unknown scope [22:17] hi will [22:17] hi gys [22:17] hi guys [22:17] shall we close rafaels actin item, or carry forward? [22:17] If someone express the desire to take over TWikiFn then it is not a waste. But I have the feeling that noone is willing to take the task of getting this matured. And I am sure the work is more than it appears on the surface [22:19] quick poll: 1 - close action item for rafael, 2 - keep open [22:19] 1 [22:20] 2 [22:20] 2 - Rafael should have a chance to say whether he wants to postpone it [22:20] I really don't want to waste work, even if the originator has done a bunk [22:20] (but I agree on Lavr's "And I am sure the work is more than it appears on the surface") [22:20] ok, keep open, for rafael to respond [22:21] # ArthurClemens: Look at code in PreInstallSmartEditAddOn [22:21] arthur? [22:21] yep [22:22] Just visited the smart edit pages [22:22] It would be good to have this functionality, but there are a few usability problems [22:22] Thomas Weigert has tested it more than most and found that performance is a huge issue. [22:22] So I read [22:22] Is that the topic lookup? [22:23] no, it's just on IE [22:23] because of the way IE works [22:23] no, it is because of limitations of ie [22:23] So that cannot be fixed? [22:23] apparemtly there is no way to query the curson pos [22:23] Colas knows about it, thinks Gael may get a chance to fix it. May. [22:23] I think it was more than one feature that was slow. And yes CDot mainly in IE. But 95% of business users use IE so ....! [22:23] so they insert a marker, and move that with keystrokes [22:23] which makes it slow [22:24] So they might need to drop a few features in Explorer [22:24] s/marker/invisible marker/ [22:24] ArthurClemens: drop a few features like..... moving the cursor? [22:24] Even if Gael will look at it - it cannot harm if someone give a hand by looking at the code and give advice. [22:24] That will be October as well for me [22:25] But to add it to pattern by default it would need a couple of usability tweaks [22:26] then there might be an author problem [22:26] how? [22:26] let us see at that time [22:26] "who owns the code" [22:26] who is allowed to poke around that code [22:26] can be also a packaging question [22:27] smartedit as an add-on to patternskin [22:27] and patternskin aware of add-on [22:27] yes [22:28] if mainatined in svn it should be ok to manage simultaneous changes [22:28] And I would need to see a proper solution for Safari as well [22:28] step by step [22:28] What I understand from Colas, the person doing the work will not be assigned forever. So if it gets integrated in the standard distro - then someone needs to take mainteneance ownership afterwards. [22:28] first get it to work on ff and ie, turned off on safari and opera [22:28] then attack additional browsers [22:30] OK, let us strive for integration [22:30] gael "has 15 days explicitely budgeted to finish a production version of smartedit starting in October" [22:30] that is quite some time [22:30] I hope it is enough [22:31] well, slow, but good timing fo your arthur as i understand [22:31] yes [22:31] any other notes before we move on? [22:32] ---+ 2. Profiling framework Update [22:32] harald? [22:33] http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework [22:33] Hm. I did an update of that topic after our last meeting [22:33] But then, real life took over [22:33] And nobody voted on the features. Whatever is in the table has been added by me from mail and #twiki [22:34] CDot said (in Bugs) that he'd like to see SmallProf. [22:34] During the last weeks, I ran quite a couple of benchmarks with both DProf and SmallProf and tried to understand the results. [22:35] Did anyone else? [22:35] no me. did you see a pattern; what do you read from the results? [22:36] 1) Platform matters. Especially windows is quite different [22:36] (comes with cygwin) [22:36] 2) Topic matters. To isolate an effect one needs to craft special topics [22:37] 3) I *think* that SmallProf would be better integrated into unit tests, to make the amount of data manageable [22:37] You can't easily compare two different implementations with SmallProf results [22:38] * CDot wanted SmallProf to help identifying hotspots, not to compare impls [22:38] i think that is a key point for developers, to be able to compare performance before and after a change [22:38] you don;t need profilers for that [22:39] all you need is Benchmark [22:39] I agree with CDot here. We have benchmark. We need to know what TWiki is doing. [22:39] if i work on search enhancements for example, i'd like to be able to compare some searches before and after the code change [22:39] Run ab [22:39] so compare on a select target [22:40] no, ab only gives you the total [22:40] i'd like to see a more granular report [22:40] We can run benchmarks today. The question we cannot answer is: "What is TWiki doing for a full second even on a flat simple topic?" [22:41] e.g. in search, where the time is spent (again comparing runs) [22:41] Ok, so again on my results :-) [22:41] 4) Compiling *is* an issue. [22:41] I found, for example, Net::LDAP to be very expensive in compilation [22:41] due to its ASN1 routines. [22:42] (it doesn't matter in my installation since I have mod_perl, though)# [22:42] But it has been reported for LdapContrib - I can confirm that. [22:43] interesting [22:43] that is good data, e.g. we can say "use ldapcontrib only udner mod_perl because of..." [22:43] can you point a finger at any of the "standard" uses? [22:43] Are there other CPAN libs we use in the standard TWiki that eats a lot of CPU? [22:43] * CDot has always been suspicious of CGI::Session [22:43] CGI::Session is quite harmless. [22:43] good [22:43] these are good questions [22:44] There has been an issue in the past with hierarchical webs. [22:44] I thought we nailed all those [22:44] I've commented on a topic without revealing that I knew from running benchmarks [22:44] Harald. Have you tried to run a Cairo compared to a Dakar to see where something has significantly increased? [22:45] Not at all. I don't have Cairo installed any more [22:45] I think between Cairo and Dakar too much architecture has changed [22:46] There are some "usual suspects" from the benchmarks: [22:46] i see two major use cases: [22:46] 1. understand existing code and fix low hanging fruits for better performance [22:46] 2. run profining before and after a code change to see impact / improve performance [22:46] Full ACK. [22:46] HaraldJoerg: please tell us your suspects [22:46] ACK? [22:47] acknowledge [22:47] Suspects: Preferences (oh, what a surprise!) [22:47] Attribute parsing in Tags [22:47] yep [22:47] Rendering major portions of TWiki markup [22:47] tables esp. [22:48] I have thought about some sort of "precompilation" of TWiki markup on save [22:48] so save is slower, but view is quicker [22:48] sounds right, although beijing and cairo did the same pref handling, var param parsing and rendering... [22:49] Yes, that's not a *new* problem. It's just that TWikis are getting bigger and bigger [22:49] pre-compilation is worth while looking into, known technology (jasp, asp...) [22:49] ...and scaling is often a problem. See the issue with hierachical webs [22:49] s/jasp/jsp/ [22:49] Yeah, and pre-compilation is a matchwinner in Template Toolkit. [22:50] precompilation is good for mostly static pages [22:50] So I'd go for pre-compilation of templates [22:50] but we are our own worst enemy with things like (e.g.) tipsplugin [22:50] Do you mean Tooltips? [22:50] only precompile static stuff [22:51] plugins make reliable precompilation really hard [22:51] because potentially, *nothing* is static [22:51] Not at all! Precompile that darned *parsing* of Tags and their attributes [22:51] the processing is already pre-compiled in perl code. [22:51] again, you can't [22:51] not entirealy anyway [22:51] Bet? [22:51] yes [22:51] 1,000,000 euros [22:52] bottle of wine? [22:52] petrus? [22:52] Bottle of Glendronach? [22:52] no way! [22:52] ther'es money, and there's whisky. Don't confuse them! ;-) [22:52] CDot: I *know* that you can't compile in the way TT does. [22:53] HaraldJoerg: let's take this offline [22:53] OK [22:53] we need Sven as well, as he has done a lot of work on precomp [22:53] agreed. good discussions for #twiki, than carry forward to codev [22:53] #twiki isn't available for me most of the day [22:53] harald, anything particular you would like to see from the dev community to support you? [22:54] Harald. I would love to see what Twiki spends its time on with a topic that says "Hello World". And nothing else. [22:54] Lavr: Install BenchmarkContrib, create that topic, and off you go! [22:55] I've done that somewhere for an empty topic to compare skins [22:55] Got lost when I switched platform [22:56] +55 min [22:56] shall we move on? [22:56] I have to go in 5 mins, sorry [22:56] What would be helpful is: How do you want to *use* Benchmarking? [22:56] was there anything specific you needed me for? [22:57] crawford: two more topics: hotfix in svn, and discontinue develop branch [22:57] any notes on these two? [22:57] crawford? [22:58] no, i think i said everything in Codev [22:58] as they say, actions speak louder than words :-) [22:58] ok [22:58] ---+ 3. Maintain Hotfixes in SVN [22:58] I would like more on the hotfix process from Lavr [22:58] I did not see any note on my Hotfix Codeb topic [22:58] Lavr: sorry, I must have missed that..... [22:59] mail me, and i'll address it in the morning [22:59] http://twiki.org/cgi-bin/view/Codev/HotFixReleaseMaintenanceSVN [22:59] crawford, that is the link [22:59] cool. thx. [22:59] g'night, all! [22:59] I captured the exact thing we discussed a few days ago [22:59] * CDot has left #twiki_edinburgh [23:00] kenneth, assuming everyone read that topic, let us know your plans, and what you need from developers [23:00] If all agrees then I can implement the thing as planned basicly. I have one doubt myself still. [23:01] Should we have a running branch or a new after each release. The latter is the easiest and I know how to do it. But the first should also be possible. [23:01] btw, thanks for proactively creating the topic before the meeting [23:02] If we run a PRODUCTION or CURRENT branch then at each release it would have to be SVN'ed up to same level as the MAIN branch. [23:03] I am not 100% sure how that is done safely. I have a feeling it is really easy. [23:03] i am not sure which one is easier/more useful [23:04] The only disadvantage of creating a new after each hotfix is that we end up with quite many branches. [23:04] personally i do not see a value in a new branch for each hotfix since we have cumulative hotfixes per release [23:05] Not per hotfix but per release! After each release a new branch is made on which only the hotfixes are merged to. [23:05] there is no need to maintain, for example, 4.0.4 hotfix 4 and hotfix 5 separately [23:06] ok [23:06] That is not the idea. Let me explain. [23:06] After 4.0.4 a 4.0.4-hotfix branch is created which is maintained until 4.1 or 4.0.5 is released. [23:06] And then you create a new branch. [23:07] Having ONE branch for all hotfixes would almost be the same except.... [23:07] ok, one branch per minor release [23:07] sorry, patch release [23:07] when a release is made the right SVN gymnastics would be done to update the hotfix branch to the release just made. That should be possble. [23:08] But I am not 100% sure how. [23:09] i think that needs to be discussed with developers strong in scm [23:09] we can assume agreement to use svn, and details to be worked out [23:10] kenneth: how about taking this offline with crawford and possibly someone else? [23:10] I will try and discuss this with Crawford. If it is easy to run just ONE then I prefer that. [23:10] ok [23:11] ---+ 4. Vote on Discontinuing use of DEVELOP Branch [23:11] http://twiki.org/cgi-bin/view/Codev/DiscontinueUseOfDEVELOP [23:11] on that topic it looks like there is agreement [23:11] I support that. This is reality already. [23:12] michaeldaum suggested to rename the svn branches at the same time [23:12] halfway reality [23:12] some people still update both [23:12] He made a wrong assumption with TWikiFn. There is actually a TWiki4 based TWikiFn scratch branch which is the most up2date. [23:13] if we officially declare it suspended we do not need to do that anylonger [23:13] yes [23:13] I think it is better that people create scratch branches when they want to test something very new which can break stability instead of using a common unstable DEVELOP branch. [23:14] ok, lets take a vote: 1 - discontinue develop branch, 2 - keep updating, 3 - bring back in sync (unit tests etc) [23:14] 1 [23:14] We know CDots position which is 1. [23:14] 1 [23:14] yep [23:15] any other votes? [23:16] looks like tea time / one more beer time etc... ;-) [23:16] Any other awake? :-) [23:16] my vote: 1 [23:17] 4 votes for discontine, no other votes [23:17] clear result :-) [23:17] Yep. [23:17] what should we do with the branch? [23:17] let it sit there? delete? (when?) [23:18] Not delete because then we loose the history. [23:18] i agree [23:19] we have an action item: update codev topics to reflect the change [23:19] But we should discontinue the ~develop on Bugs. [23:19] CDot already cheat started on the some of it like discarding develop only bugs. [23:19] yes, simple redirect to equivalent in _twiki4 [23:19] ~twiki4 [23:20] do you think we can give sven in absense an action item? [23:21] redirect to proper web.topic from ~develop to ~twiki4 [23:21] We can try. [23:21] and crawford in absence to finish update of codev topics? [23:22] any other action items? [23:23] That is less natual that it should be him. I think we should take that action as a team even if we wrote Crawford on the action [23:23] good point [23:24] ok, any other items? [23:24] One thing. Should TWiki4 branch be renamed to MAIN as earlier agreed? [23:24] otherwise i think we finish the meeting, ready for beer, dinner, lunch, sauna, or whatever people like to do :-) [23:25] yes, i think so [23:25] The current name TWikiRelease04x00 will soon be very odd. [23:25] yes, we can ask sven to rename the branch in svn [23:25] At some point in the future we'll need to revisit WhatIsIn04x01 [23:26] In principle it is a matter of copying the whole thing to MAIN. There will be some cleanup to do on develop.twiki.org though. [23:26] And developers needs to know when so they can "cut over". [23:26] yes, that needs to be coordinated [23:27] can thsi be done in codev, or needs to be discussed in next meeting? [23:27] Let is make a Codec topic. [23:27] us make [23:27] Will you take that Peter? [23:28] yes, i will create Codev.RenameTWiki4BranchToMAIN [23:28] Last thing for today. A small proposal. [23:29] I propose that until we have the ChangeRequest process setup on Codev topics people want evaluated should be added as simple WikiWord links to WhatIsIn04x01 [23:30] Which is what in reality has happened until now. [23:31] yes, that is what we currently have, and what should be used until we have the change proposals adapted for the change [23:31] ok, lets close the meeting at +90 min [23:31] OK. Minutes are ready in 5 minutes. [23:32] Thanks all. [23:32] tahnks all! [23:32] Have a nice day/evening/night!