Session Start: Tue Jul 18 07:01:34 2006 Session Ident: #twiki_edinburgh [07:01] * Now talking in #twiki_edinburgh [07:01] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x07x18' [07:01] * Set by SvenDowideit on Tue Jul 18 03:38:42 [07:01] Good morning. [07:01] bugger. [07:01] just as i was going to quietly voluenteer you :) [07:01] For the minutes? [07:02] to bring us all a round of coffee [07:02] with a nice whisky in it i think [07:02] Dammed. I forgot to turn on the coffee machine. [07:02] hi arthur, crawford, kenneth, micha, rafael and sven! [07:02] blimey, you northern europeans don't get coffee do you [07:03] has to be made by the highly skilled barista! [07:03] crawford, are you a morning person? [07:03] is very early for you [07:04] its the evil robot CC [07:04] who else might join? [07:05] I have an expensive fully automated machine that grind the coffee and makes the coffee. Normally SWMBO is the barista. But I am alone this week. [07:05] hehe [07:06] anybody heard if lynnwood will join? [07:06] i thought he had similar tz to meri [07:06] he is one hour later than me [07:06] e.g. 11pm for him [07:06] 10pm for me [07:07] tbh, i think we need to tell the europeans to quit theri day jobs [07:07] so they can be more flexible with meeting times [07:07] meeting topic is at http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x07x18 [07:08] who is going to take the minutes? [07:08] I have started [07:08] cool! [07:08] who is facilitating? [07:09] i recon thats me :() [07:09] so be ready for chaos! [07:09] thanks for volunteering [07:09] shall we start now, or give 'them' 5 minutes more? [07:09] it's already +10 min [07:09] I have 50 minutes [07:09] we might as well start [07:10] ok - 1. [07:10] doc group [07:10] we met last weel for the second time [07:10] we keep track at http://twiki.org/cgi-bin/view/Codev/TWikiOrgDocWork2006 [07:11] progress, slow but surely [07:11] We got some good decisions made. [07:11] we will implement some low hanging fruits first [07:11] to show some results [07:12] I see 'additions' but am curious if there are any things being removed / reduced [07:12] 'Work in progress' plugins home in http://twiki.org/cgi-bin/view/Plugins/WebHomeStudy2006 [07:13] such as removing the support web? :-P [07:13] i was trying to be serious [07:13] we focus on twiki, plugins and support web [07:14] some skin improvements, better navigation, and redesign of home pages [07:14] And not Codev since the original target for the team was customer focused part of twiki.org [07:15] so no simplification? [07:15] You have a proposal Sven? [07:15] no, i have questions [07:15] simplification in home pages and navigation, yes [07:15] if i had answers, i'd give those instead [07:16] in the interim, anbody can help improve the supplemental docs, see http://twiki.org/cgi-bin/view/Codev/ProposedInterimDocGuidelines [07:16] ie i struggle with the idea that making 10 new topis to simplify the home page is as good as removing 20 other topics [07:16] does anybody have feedback/requests to the doc team? [07:17] If you look at the Plugins WebHome proposal you will see that to the user arriving things will be simpler. [07:17] Less links. Better navigation. [07:17] ya, but what about the next and next steops? [07:17] please, don't take my q's as discarding the good [07:18] twiki tour, and other customer focused docs [07:18] just as a wondering about the nexts [07:18] cos much of the complaint seems to me to be about the sheer volume [07:18] A big decision was a new web for TWiki Applications. But it will not be created until we have the "infra-structure" ready. Ie. all the creation docs and forms and templates. [07:19] typical problem with large data: how to navigate an find stuff (e.g. not so much the question how to remove stuff) [07:19] And it will be based on same design as we currently make for Plugins web. [07:19] i personally recon that the remove stuff is the bigger q [07:19] which is why people try to ignore it [07:19] thats why good prose writing is considered such and art [07:19] every topic is quite stuffed on twiki.org [07:20] an [07:20] not only their count [07:20] sven, we will take your suggestion as input for the next doc meeting [07:21] thanks :) [07:21] +20 min [07:21] http://twiki.org/cgi-bin/view/Codev/OrganizeTWikiVariables [07:21] mostly a reminder [07:21] has everyone provided feedback? [07:22] micha, could you summarize where we stand and what you need from us? [07:22] wrt to twikiapps? [07:22] twiki vars [07:22] from twiki prefs [07:22] That was Harald. [07:23] oh, yes, sorry [07:23] I haven't followed twiki var docu, sorry [07:23] ok, lets defer this til later in the meeting [07:23] harald stated "back to the drawing board" [07:23] he als might be in later [07:23] http://twiki.org/cgi-bin/view/Codev/TWikiReleaseManagerRole [07:24] action item for all: provide feedback, so that harlad can create a proposal & implement it [07:24] i considered this 'role' as being a comunity role [07:24] shall we talk about that role in item 3? [07:24] ok [07:25] ArthurClemens, download page? [07:25] and hot fix vis - anything happen there since the work Lavr did? [07:25] * CDot peers at the world through bleary eyes..... [07:25] CDot, Lavr's on the way with coffee :) [07:25] thank god [07:25] Morning Crawford. [07:26] Lavr did a modification on the download page [07:26] morning crawford! [07:26] I think the need for the download page change is no longer there because of the new HotFix release concept. [07:26] and its good enough for now - still feel it could be better structured visually [07:27] yes, download page looks good with the latest change [07:27] * HaraldJoerg has joined #twiki_edinburgh [07:27] holla HaraldJoerg :) [07:27] ok, lets go back to [07:27] hi harald [07:27] I added a simple link below the download page as quick and dirty solution but it seems to work well. [07:27] G'morning Harald. [07:27] the devil appears when we speak of him ;-) [07:27] Holla - I'm not really there - have to leave to bring the son to school [07:27] HaraldJoerg, ok, we'll talk more of your vars work when you return [07:28] harald, any quick feedback on what you need from us on twiki vars? [07:28] Just a decision would be fine. Any one :-) [07:28] 'outlook is bad'? [07:28] I'd suggest to postpone it because it needs some thinking work, more than fits until september [07:28] I think Harald is helping on a need that my users have. But the actual implementation will be hard to maintain. [07:29] we could split it up into two phases [07:29] ok, lets leave this til some time when HaraldJoerg has time.. [07:29] 1. low hanging fruit - just the most important few vars from twikiprefs topic [07:29] 2. twiki vars with categorization [07:30] rather than dividing his attention here and with his kids [07:30] +30 min [07:30] big new(old) item [07:31] how do we get (anyone) to take the performance torch? [07:31] i don't recal my work on it with fondness [07:32] I think THE task is really profiling. We need to know where the time is spent. We do not have a clear picture today. [07:34] If we just keep on adding new features to TWiki - it will get slower and slower until noone can use it for anything. [07:36] * SvenDowideit has quit IRC (clarke.freenode.net irc.freenode.net) [07:36] * PeterThoeny has quit IRC (clarke.freenode.net irc.freenode.net) [07:36] * Soronthar has quit IRC (clarke.freenode.net irc.freenode.net) [07:36] * ArthurClemens has quit IRC (clarke.freenode.net irc.freenode.net) [07:36] * HaraldJoerg has quit IRC (clarke.freenode.net irc.freenode.net) [07:36] Dammed. Netsplit [07:37] * SvenDowideit has joined #twiki_edinburgh [07:37] * HaraldJoerg has joined #twiki_edinburgh [07:37] * ArthurClemens has joined #twiki_edinburgh [07:37] * PeterThoeny has joined #twiki_edinburgh [07:37] * Soronthar has joined #twiki_edinburgh [07:37] We had a netsplit. [07:37] big new(old) item [07:37] how do we get (anyone) to take the performance torch? [07:37] i don't recal my work on it with fondness [07:37] and wonder if others have similar feelings [07:37] i presume you're all quiet because you're afraid that speaking up means you're voluenteered to work on it? [07:37] a top 10 list will help us focus on the most urgent performance issues [07:37] welcome back micha, crawford, kenneth [07:37] i didn't see anything from you guys :( [07:38] [07:32] I think THE task is really profiling. We need to know where the time is spent. We do not have a clear picture today. [07:38] [07:34] If we just keep on adding new features to TWiki - it will get slower and slower until noone can use it for anything. [07:38] i agree that BM is very important [07:38] but unless there is joy in the fixing [07:38] * SvenDowideit_ has joined #twiki_edinburgh [07:38] BM will only be more un-happy [07:38] Not only BM. That is a summary measurement. We need to know where the time is spent. [07:39] PeterThoeny: i think there are two questions to improving performace: [07:39] 1. establishing profiling standard/framework/mindset [07:39] 2. rearchitect twiki evoluntionary for better performance [07:39] PeterThoeny: item 1 can be done for 4.1 [07:39] PeterThoeny: item 2 might be too big for 4.1 [07:39] ok, i mean all measurement [07:39] PeterThoeny: once we profile twiki i am sure there are many places we can improve performance [07:39] PeterThoeny: as we have seen with the sub-webs performance improvement on web topic list [07:39] ok, so you are not at all worried about the people aspect? [07:40] to me the tech aspect is less than half the problem [07:40] 1.5 make experiments on a standard hw [07:41] what is "BM"? [07:41] benchmarking [07:41] aka measuring [07:41] oh, yes [07:41] the easiest part of the equation - and even that we're not doing well at [07:41] Why is it not fun to profile and optimise the code Sven? Noone has ever really done it on TWiki. We have only measured the total execution time. [07:41] no-one? [07:41] i know i have [07:41] other open source projects have bug stomping weeks [07:41] and cdot has [07:42] how about a performance hunting week? [07:42] Then you have kept it secret! [07:42] no, we've not [07:42] So where are the data? [07:42] PeterThoeny, if you think you can get the buy-in, then yep [07:42] thats the problem, the data is horribly inconculsive [07:43] I spent a *long* time working on performance; I am not enthusiastic to do it again [07:43] how can me make it easier to get the buy-in? [07:43] and disgustingly variable in its results [07:43] mainly because all i got in return was flamed [07:43] PeterThoeny, thts my question [07:43] WHERE is the data? [07:43] _that_ feels like another flame [07:44] Lavr: there is data all over a variety of topics in codev [07:44] I was publishing benchmark results for some months [07:44] as you probably recall [07:44] however that data is no longer relevant [07:44] Cairo was slow. Dakar is slower. And I have not seen any data that shows which parts of the code consumed how much time. [07:44] thats the problem, the data is horribly inconculsive [07:44] Lavr: you have been part of the discussion as to why that is [07:45] and disgustingly variable in its results [07:45] +45 min [07:45] ie, more of a distraction and hinderance [07:45] it is inconsistent because everybody set up his own bm env [07:45] n [07:45] so how about one env everybody uses [07:45] its inconsitent over the same env [07:45] also a result [07:45] ignoring variablity over different ones [07:46] So you just want to code and code and code until the project is destroyed by poor performance and being payed for it? [07:46] no [07:46] no [07:46] if that was the case i'd not bother to bring it up [07:46] yes >:-) [07:46] Lavr, you're pissing me off [07:46] benchmarks are good, and profiling is better [07:46] PeterThoeny: that isn't true, I'm afraid [07:46] how about a profiling standard/tools for developers to use? [07:47] to return on topic [07:47] You ask for it Sven. YOU are provoking my statements. [07:47] benchmarks and profiling are good *if they tell you what is going on* [07:47] what are we able to do to help developers _do_ something [07:47] not just what are the easy thing [07:47] but how do we make it enjoyable to look into perf [07:47] cos without warm fuzzies [07:47] We need profiling. We need to know what part of the code takes which time. There is no way around it. [07:48] there are more enjoyable things to do [07:48] yes [07:48] no argument [07:48] Actually, no [07:48] but the measurement is useless [07:48] we need to know which parts of the *system* take time [07:48] if you don't get buyin and enjoyment in doing somethign about it [07:48] not just *code* [07:48] the browser has a major impact [07:48] well, for me if a have a profiling tool at hand i would use it to see how the twiki code works before and after my change [07:48] You *do* have a profiling tool at hand!!!!! [07:48] since we do not have a tool / standard i do not do it [07:48] You have chosen to ignore it!!!! [07:49] considering how many people commit without running the unit tests [07:49] and the benchmark.pl [07:49] AthensMarks has been in place for a YEAR! [07:49] having a tool seems kinda depressing [07:49] athensmarks is not profiling. It is BM of the total code. [07:49] *sigh* it include the 'prof' script [07:49] which does fine-grain profiling [07:50] don't believe that everything in profiling can be standardized [07:50] hold on; let's not solve it here [07:50] all we want is a champion [07:51] Then I can just repeat myself. Where is the data that shows this fine-grain profiling? If we had that data we would already be working on improving the slow parts [07:51] Sven and i have both tried that role, and failed [07:51] ...I'm back... [07:51] and i'm going to repeat [07:51] i do _not_ ask for a technical solution [07:52] harald: we are at 2. performance [07:52] i ask: is there anything that will allow people to _want_ to work on improving perf [07:53] If the most skilled and most active developers just code and code more feature and leave performance to others because you are "pissed off" then we will NEVER get any improvements. [07:53] i want to do it if it is easy to do [07:53] I think an easy-to-run comparison before/after a change will help [07:53] pool Lavr [07:53] the _only_ work i did on 4 was perf [07:53] people will be rewarded for profiling by people getting value back from it [07:53] really? [07:54] i don't feel rewarded for _any_ of the weeks i worked on it [07:54] and thats why i asked [07:54] ok [07:54] times up, buggerit [07:54] PeterThoeny: you say you will do it if it's easy to do. AthensMarks is easy to do. prof is easy to do. [07:55] 3. TWiki 4.1 release process & proposed items [07:55] Harald you had some ideas on profiling? [07:55] it is not in the mindset, and i do not know how "easy" it is [07:55] http://twiki.org/cgi-bin/view/Codev/TWikiReleaseManagerRole [07:55] TWiki:Codev.BenchmarkFramework [07:55] Sorry: http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework [07:55] * wbniv has joined #twiki_edinburgh [07:55] we can worry about the tech bits outside [07:56] My idea is to prepare a form like that on http://munich.pm.org/cgi-bin/view/Benchmarks [07:56] so long as i can run it from unit test like things [07:56] To get results like http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_6 [07:56] cos the web view is not as useful when building [07:57] ...or http://munich.pm.org/cgi-bin/view/Benchmarks/Tools_MiniAHAH_5, same topic, different skin [07:57] harald, that is exactly it! [07:57] In the same fashion I'd like to have ready comparisons with/without a patch [07:58] which, technically, is a bit more difficult if the all I have is a unified diff [07:58] That looks very good Harald. [07:58] I am not sure the munich stats are so informative [07:59] ie who called the expensive function [07:59] and how many counts [07:59] ^counts^times [07:59] if i see that Locale::Maketext::Lexicon::Gettext::transform gets called 1350 times i know where to focus my effort [08:00] MichaelDaum: The times are there (# Calls) [08:00] And the idea is to allow on-the-fly configuration changes [08:00] ...or on-the-fly module exchange, just for one request [08:01] harlad, you are up to somthing very useful [08:01] the bin/profile script currently is calling view (or maybe something else) from the command line [08:01] and is changing whatever it needs by adding -I/my/modified/libs -MTWiki::Client (for example) [08:02] Harald - how do you propose that we get more involved using and developing these tools? [08:03] idea for enhancement: take a snapshot, and compare it with the next profiling run (e.g. after some code changes) [08:03] First - check what exactly you *want* to do [08:03] PeterThoeny: You have your "snapshot" since every measurement is kept around [08:04] I am abusing XXXXXXXXXX technique [08:04] oic [08:04] cool [08:04] (and I really mean *ab*using, since I jump straight into the save script right now) [08:04] warning: you will see wide variation in profiles *between runs of the same code* much less between runs of changed code [08:05] I mean *wide*. Up to 25% performance shifts [08:05] if i can easily identify what changed for the modules (times called & time) when i change my code, it will be more natural to do the profiling [08:05] CDot: I had variations only between the first, and all the consecutive runs. Swapping, I'd assume [08:05] (i as in us in general) [08:05] But running and averaging a number of runs is on the agenda [08:06] HaraldJoerg: you are lucky. AthensMarks throws away the first result for that reason [08:06] and averages over a lot of runs [08:06] and *still* shows variance [08:06] so good luck [08:06] :-) [08:07] there are two approaches: either (1) a detailed bm plan for broad coverage, or (2) hunting down one specific cpu hog ... most of the time people are interested in (1) first but then need to do (2) on their own [08:07] I knew about the hierarchical web issue because of exactly that tool :-) [08:07] that depends on how much load on server, if measuring across the net or not, etc. [08:07] HaraldJoerg, so did we [08:07] i made an even broader reaching fix to it [08:08] but it was demed to be too close to release to use [08:08] I wish it did, Peter. I run on a dedicated stand-alone server, with no other load (except, IIRC, IRC) [08:08] There's always variance due to the sampling technique in DProf. [08:08] anyway, the key point is, even if we have a framework that is useful, PEOPLE NEED TO RUN IT [08:09] Yeah. Like the testcases. [08:09] people will run it if it is a no brainer to use :-) [08:09] a permanent BM server with profiling would be great [08:09] yep [08:09] sitting doing nothing but running tests and publishing results [08:09] CDot: Be aware that some effects are different on different platforms [08:09] Even if I do not code much, I could use such a tool to try many different test pages and see how different features consumed time and where. [08:09] HaraldJoerg: I'm well aware of it! [08:10] Lavr: yes [08:10] CDot: Ok :-) Otherwise I'd have given you some hints how to really achieve slow loading of many little modules as compared to one TWiki.pm [08:11] heh; thanks, harald! [08:11] Can we define some action items? [08:11] Sorry, I have to go [08:11] for work [08:11] BTW as part of my performance exercises in the past, i also tried (1) autoload and (2) collapsing all code into a single .pm [08:12] you are welcome to repeat the experiments of course [08:12] * ArthurClemens has quit IRC ("Leaving") [08:12] I tried the same with all the Pattern templates. And had zero performance degradation. [08:12] what was the lesson learned, CDot [08:13] autoload slowed everything down, a lot [08:13] CDot: I've done autoloading with the traces I found in the code, just to get a feeling for it. [08:13] packing all into a single .pm made no difference [08:13] no *measurable* difference [08:13] so its somewhere in between [08:13] yep [08:13] grr [08:13] plugins have a major impact too [08:14] CDot: I'd *not* go for the standard autosplit/autoload method. [08:14] right [08:14] we do not need to solve technical details at this meeting [08:15] but we can look for general direction and new ideas [08:15] No - we are at the point where we need a few action items [08:15] a bm server can not address every idea in detail but protect us from doing a bad release so to say [08:15] I'd like you to check the section " Wishlist" in http://twiki.org/cgi-bin/view/Codev/BenchmarkFramework and add your wishes [08:16] ok, that is an action item for all [08:16] PeterThoeny already mentioned sort of a "memory" to obtain differences between two experiments [08:17] What actions are need for anyone to easily run a full profile? [08:17] needed [08:17] me: get a hands on feeling about the tools [08:17] harald: what you just showed us could be a useful profiling framework for twiki [08:19] what action items do we have? [08:19] At the moment I'd like to collect *requirements* and *wishes* [08:19] ok, lets do it [08:19] and discuss on next meeting [08:20] is this achievable for 4.1? [08:20] should we have this on the 4.1 list? [08:20] sven, around? [08:20] or is it outside that box? [08:20] we've not even gotten to item 3 [08:20] +80 min [08:20] we're still on 2 - is tere anything we can do to get people to _want_ to improve perf [08:21] performance _is_ very important [08:21] Well. I added performance on the wish list. And if we can get profiling into 4.1 then it is a good start. [08:21] we will lose market share if we do not address performance [08:21] agreed with kenneth [08:22] It needs only rather minor changes to the code, the rest is a Contrib [08:22] Even better then. [08:23] move on? [08:24] ok [08:24] OK [08:24] http://twiki.org/cgi-bin/view/Codev/TWikiReleaseManagerRole [08:24] imo this is a non-core, non dev role [08:24] someone unencumbered by those biases [08:25] nevertheless it must be someone with a certain insight [08:25] IMO it is a community role. I do not like the idea to begin with. [08:25] Lavr, i'd agree, but: [08:25] each release has had this role by default [08:25] its one of the major things that burns out the lead dev [08:26] what i read between the lines is: question of scope for release manager responsibility [08:27] I like CDot's proposal [08:28] We wouldn't pick a moron for that role, would we? [08:28] we get to pick? [08:28] *someone* has to take responsibility [08:28] personally i feel that an all empowering role could backfire, e.g. if done with developer focus [08:28] instead of customer focus [08:29] at the moment, we are often paralyzed by a lack of (1) feedback and (2) decisions [08:29] thats why i suggest a non-dev & non-core [08:29] That is my fear too. It is too much power to one person. [08:29] then share the role [08:29] ok, fear seems to me to be the biggest thing this project has [08:29] but among a *small* group, that can *make* decisions [08:30] I can't understand that fear. We can re-assign the role for every release [08:30] let alone that the idea of wiki's is that there is no need for fear [08:30]