Session Start: Mon Jun 04 22:04:38 2007 Session Ident: #twiki_release [22:04] * Now talking in #twiki_release [22:04] * Topic is 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x05x28' [22:04] * Set by CDot on Mon May 28 19:30:06 [22:04] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x06x04 [22:04] Good evening. [22:04] hi kenneth [22:04] Hi Kenneth [22:05] just finished a pizza lunch at home [22:05] frozen ready pizza imported from italy [22:05] quite tasty actually [22:05] 100 x better than the american pizza [22:06] is sven here physically? [22:06] Maybe I got disconnected in the near future. My connection is not very stable today. :-( [22:06] PeterThoeny: sven_ was last seen heading for his supper [22:06] about 1/2 an hour ago [22:07] * CDot changes topic to 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x06x04' [22:09] small group today [22:09] shall we start? [22:09] who is taking the minutes, who is facilitating? [22:09] I am on the minutes already [22:09] tahnks [22:10] and i can facilitate as usual unless someone is inclined to [22:10] proposed agenda: [22:10] # 1. Action Item Review [22:10] # 2. Maintenance of develop.twiki.org Server [22:10] # 3. Review Proposed Features [22:10] # 4. Coordinate TWiki Release 4.2 [22:10] anything to add? [22:11] ---+ 1. Action Item Review [22:11] # Kenneth changes all proposals not yet implemented to Georgetown. [22:11] marked as done [22:11] Yep [22:11] no other action items here [22:11] more to come later [22:11] * ArthurClemens has joined #twiki_release [22:11] ---+ 2. Maintenance of develop.twiki.org Server [22:11] hi arthur! [22:11] yes I move the AI to the agenda points where they belong [22:12] hi, sorry I'm late [22:12] twiki.org is hanging. Not good for minutes [22:12] # Desired outcome: Resolve the server error asap; clearly define who is driving the server maintenance; get shell access to all core team members [22:12] Finally saved. Took over a minute [22:13] hmm, load is light on twiki.org [22:13] hi there [22:13] hi Steve [22:13] Hi Arthur [22:13] hey Arthur [22:13] is sven here, or sleeping? [22:13] on develop.twiki.org server issue [22:14] i called support again last night [22:14] they want a case where they can verify the issue [22:14] It was a specific person that originally decided to donate the server. Can we contact him? [22:14] sven replied by email, i added his comment to the tocket [22:14] PeterThoeny: can't they just use hdparm? [22:14] "ticket" [22:15] can't we just pay for a new disk? [22:15] ok [22:15] CDot: that is what sven suggested [22:15] yes, to speed up things i am ready to pay for a disk [22:15] if needed [22:15] me, too [22:15] but we have a fundamental issue to solve [22:16] too many cooks spoil the broth [22:16] who are the cooks? [22:16] (slow tonight) [22:16] it is not my task to maintain d.t.o, i assumed that crawford and sven are the drivers [22:16] i am more than welcome to help out if asked [22:17] ... and I wasn;t aware I was an admin. I always assumed it was Peter :-/ [22:17] but it is not me who is supposed to drive the support request [22:17] i was not involved in the d.t.o server setup [22:17] i just helped out in the logistics in the beginning [22:18] so, looking at the support ticket i can see that their support is very responsive [22:18] can we formalize this? [22:18] the long delay is caused on our side [22:18] between replies [22:19] sven_ said he was going to call (phone) their support people [22:19] though the time difference is a problem [22:19] I think YOU should take the ball now Peter. Ask them to change the disk no matter if it is broken or not and send the bill. We are plenty it seems that will "spit in the box" [22:19] sven assuming i follow up on the ticket, me assuming sven is following up on the ticket he opened [22:20] Lavr__: i did ask them to change the disk [22:21] Did they refuse? [22:21] ok, i jus tasked again to replace the disk and to send me the bill if needed [22:22] what day shall we pick for the downtime? [22:22] Any. [22:22] ASAP [22:22] any; just warn us [22:23] The current DH solution sucks. I cannot save from home. I cannot save from work. I have to edit and save on an anonymizer to raise bugs which means I do not raise or edit half the bugs I should [22:23] "Please let us know the timeslot of downtime so that we can alert the developers. Replace asap please." [22:24] Can you contact the guy that originally got us the server? [22:24] Always good with an insider. [22:24] ok, that is all we can do at this meeting about "resolve the server error asap" [22:24] ok i will [22:25] on desired outcome of "clearly define who is driving the server maintenance" [22:25] who is driving the maintenance? [22:25] it can't be me, i have too many things on the plate [22:26] How many people do we need to drive the box? [22:26] what is needed for the task? [22:26] just one to do the admin [22:26] and look after subversion [22:26] Sven and I already look after the twiki installs [22:26] One to do admin. But with core team access to fix emergency issues when something hangs up. [22:26] no reason for that to change [22:27] Lavr__: yes, that is the third of the desired outcome [22:27] lets first confirm who is maintaining the d.t.o server [22:27] can we do that without sven_ here? [22:28] sven_ around? [22:28] I can talk to sven and see what skills are needed and decide if I am fit enough for the job. [22:29] great move! thanks oli! [22:29] Thanks Oliver. [22:29] I dont know yet, if I am... ;-) [22:29] Is Sven back down under again? [22:29] nope [22:29] until confirmed otherwise i assume sven and crawford as the primary maintainer [22:29] ACK [22:30] hold on a mo... [22:30] I only do the twiki - I know nothing about the platform [22:30] but I will help where I can. [22:30] It is red hat right? [22:30] ok, that looks like a good distinction [22:30] Centos, I believe [22:30] irx,... okay... :) [22:30] Same I run Centos too [22:30] yes, centos [22:30] though Sven wanted to Debianise it [22:31] I like Svens ideas... ;) [22:31] we would loose the prime support though [22:31] Centos is fine. [22:31] I know it well. It is rock solid. [22:31] its a derivate of RH ? [22:31] It is RH 99.999%. Only logos are changed [22:32] ok [22:32] I admin 3 Centos machines now. Easy. [22:32] rock solid logo [22:32] minus some proprietary monitoring tools of rh i think [22:32] yes, centos is very good [22:33] Yes. minus the stuff they use to charge for upgrades [22:33] ok, lets moe on [22:33] desired outcome: "get shell access to all core team members" [22:34] i think so far there are shell accounts for crawford, sven and peter [22:34] Yes. When something hangs up I do not want to wait 2-3 days again that it has happened when someone was travelling [22:34] yes, all active core team members need access [22:34] That does not mean I will walk in a change things all the time. Not at all. [22:35] I won't fuck up. promise [22:35] meaning we should add kenneth, arthur and richard [22:35] although if a core tema member does not intend to login ever we should not create an account [22:35] for security [22:36] richard possibly does not want/need one [22:36] action item for sven/crawford: create account for kanneth and arthur; ask richard if he wants one [22:37] ah, i see kennet halready listed that a.i. for sven [22:37] anything else on d.t.o? [22:38] My connection slowed down to 2 bits/s. I think, its time to leave. [22:38] if not, next item [22:38] ---+ 3. Review Proposed Features [22:38] only one item i think [22:38] kenneth? [22:38] Yes same as last week. [22:38] anything else besides http://twiki.org/cgi-bin/view/Codev/SearchWithTWikiQueryLanguage ? [22:39] cu, folks [22:39] One of my staff gave his oppinion. Mostly in favour of CDots syntax. And without having talked to me he also asked for that the simple syntax is there. Without dots [22:39] by Oliver [22:39] * OliverKrueger has left #twiki_release ("Konversation terminated!") [22:39] bye oli [22:40] Another one gave me feedback in Danish. His view was mainly that it should be kept simple. [22:40] Easier said than done :-( [22:40] "kept simple": he can use the current syntax [22:40] Not really. Your proposal has the simple syntax. And they both like that [22:41] I think it is easy to learn [22:41] The simple syntax is extremely easy. [22:41] there are a couple of nasties waiting for us [22:42] tell us the bad news [22:42] but we will need a SearchQueryCookbook [22:42] yes [22:42] I would love someone to do a SEARCH wizard [22:42] sven_: started one, but never finished [22:42] to do what? [22:42] a UI to help developing searches [22:42] ok, yes [22:42] it would tell you what it had searched, what it had matched [22:42] yes, a search wizard would help a lot [22:43] a sort of search debugger, I huess [22:43] that is what i was referring to with auto complete [22:43] right [22:43] it could be JS + AJAX [22:43] a neat student project [22:43] getting auto complete with X[query] done looks overly complex [22:43] Peter: can be done in a popup first, then copy-paste [22:43] Yes. Good student project. But for 4.2.0 we mainly need two things... [22:44] Get the syntax done, tested and documented [22:44] AND get the performance "acceptable". [22:44] I have unit tested, and documented [22:44] I know the perf is bad, for reasons I gave you [22:44] It will not be good until we get the new storage model. [22:44] dunno; maybe someone could do some work on optimising it [22:45] The most simple search for a fixed value - not even a regex - can for sure be optimized. [22:45] in that case, wht use a query? [22:45] i retracted my proposals not because they are bad, but because i have seen no progress in discussion. my goal for 4.2 release is to have a kiss solution that does not necessarily have all the power crawford wants [22:45] kiss so that we do not limit us in the future [22:45] SEARCH{ "Firstname='Kenneth'" type="query"}% [22:45] ah, there's the rub. If we try to be *too* simple, we *will* end up limiting ourselves [22:46] THAT needs to get optimized. [22:46] And for sure it can be [22:46] heh; I tried (after our conv on it before) [22:46] it's a lot harder than it sounds [22:46] one thought I wanted to raise was the possibility of "mixing" query types [22:46] If the old search can search in META and find the same twice as fast - then for sure the simple search can too. [22:47] Lavr__: you are wishing on a star.... [22:47] anyway, nested searches can help a lot [22:47] if i have a choice to push out a powerful & complex syntax now, or to deliver a kiss solution with some limitations (but giving us room to decide a solid syntax later on), i'd opt for the kiss solution [22:48] What I did was the most simple set of Searches in my little tiny Motion web. It took 14 seconds instead of 8 as I remember. [22:48] We cannot release a feature with performance like that. [22:48] yes, because in the simplistic implementation it opens and reads every topic, every time [22:48] I told you this [22:48] there is *no* optimisation [22:48] it is brute force, proof-of-concept [22:49] And the conventional search looking for ONE value in meta? [22:49] that uses either grep or NativeSearch; c-code optimisations [22:49] CDot: what next steps should be taken to improve performance? [22:49] to compare like-with-like, compare with PurePerl search [22:49] ArthurClemens: there are three approaches [22:50] one is to do sme simple optimisations, such as Lavr is talking about [22:50] that basically reduce the number of topics that have to be searched [22:50] the second is to layer a cahce mechanism, similar to the DBCacheContrib [22:50] (it could even re-use that code) [22:51] the third is to go straight to DBI, and cache the DB in DBI instead of in files, as they are at the moment [22:51] Yes. in 5.0 we need all this. But right now we have to just make simple plain text fixed text searches as fast as looking for the same value with the geeky old search. [22:52] why use 'query' now, everywhere? [22:52] good question [22:52] I don;t [22:52] I would only use it where it makes a big difference [22:52] We only had query for a few weeks in SVN. Naturally none of us use it. [22:53] e.g. in complex searches that would otherwise have to be nested [22:53] it's been said we need to have experience with the new syntax, to be able to use it for 5.0 [22:53] I used in - for example - Bugs web [22:53] where I rewrote the searches to use it [22:53] i agree that we want to have something in 4.2 to learn [22:53] No. I wanted the syntax in 4.2 so that people use that instead of the old - when we come with 5.0. [22:53] only kiss is ok [22:53] If the new search does not work properly in speed it should not be in the release [22:53] Lavr__: you can't have everything, I'm afraid [22:54] you may have to compromise on performance in 4.2 [22:54] We can have simple query searches as fast as the old search. I know enough about programming to know that [22:54] Lavr__: i think performance is important, but a solid syntax is way way more important [22:54] performance can be fixed in later releases [22:54] a syntax cannot be fixed later [22:54] that's my attitude as well [22:54] * wnorris_ has joined #twiki_release [22:54] NO. I am out of the project if this becomes the outcome [22:54] he will! welcome [22:54] ^he^hey [22:55] [off] hi, thanks. just got in; had to go to court for a friend for a speeding ticket [22:55] Hi Will. [22:55] Lavr__: can you offer some programming support to make it a reality? [22:55] hi will! [22:56] Lavr__: for exmaple, building benchmarks and testcases? [22:56] is there a backlog i can read? sounds like i walked into the middle of something! :-O [22:56] yes. No problem. Remember I am only looking for the simple searches for one or two value to be par with the current geeky regex search in meta. [22:56] And regex search in meta is already not very fast. [22:57] ok; here's the programming support I need; fix the bugs [22:57] it should be possible to convert a simple search into the same code that searches today [22:57] if I know someone is working through the bug DB, it's a buig load off me [22:57] wnorris_: log is on the way to your gmail account [22:58] having Will picking up on stuff has been a big help [22:58] but it's a case of "the more the merrier" [22:58] if I can leave bugs web alone for a week or two, I can certainly optimise DB searching. [22:58] Why should it be impossible to make %SEACH{ "BugStatus='New'"..... as fast as %SEARCH{ "[B]ugStatus.*(value\=).*[N]ew" ? [22:59] PeterThoeny: thanks [22:59] who said it was impossible? [22:59] it's not impossible [22:59] it this kind of simple search for a value in a form that I just want to see as fast. BECAUSE I want the users to start using the new search this way. [22:59] Lavr__: I hear you. Now hear me. [23:00] organise our resources (such as they are) to tackle bugs web, and I'll deliver you that performance [23:00] but as long as I am the only only coder working on closing bugs..... [23:01] time chack: +60 min [23:01] You know I am fighting hard all the time to get bugs closed. And I have also said many times that you are one of the few killing bugs. [23:01] s/chack/check/ [23:01] So I will continue along that road Crawford. [23:01] (i have to leave at +90 min) [23:01] sure, sure, I know. I'm just telling you what we need to do [23:01] shouting about it doesn't help :-( [23:02] That was already my plan. Get this last proposal out of the way. And then focus 100% on bugs [23:02] 8-) [23:03] All left now is to get Sven's last work stable. The user mapping and the admin user stuff. [23:03] that will happen. I'm far more concerned about doc [23:04] Doc is my best [23:04] I read through the TWikiScripts doc the other day, for example, and it's incomplete, and may be wrong [23:04] all the user doc stuff needs to be reworked to decouple the TWikiUsers/htpasswd assumptions [23:04] reply from fastwerver.net support: "I do not believe that the issue is with the drive itself. The slow speeds are due to DMA not being enabled. I am investigating why this is occurring. It may be necessary to reboot the server into a new kernel or take it down to check BIOS settings, so please be aware of this. Thank you and we will let you know what we find out." [23:05] PeterThoeny: well, that 's better than a kick in the teeth.... [23:05] Yes. First positive news until now [23:06] Peter. CDot. Have you learned to live with each other with respect to the syntax? [23:06] on the new TQL? [23:06] I think I have addressed all of Peter's concerns, so from my side, yes. [23:07] Taken the current spec (Peter there is a spec on SVN) anything in the advanced syntax that should be adjusted? [23:07] i expressed my opinion many times already: i find the existing syntax with shortcuts too unspecific (such as no specifier for field), and too complex with the x[query] syntax [23:08] I love the simple and as you could see both my users did too. [23:08] i am concerned that this will limit us in the future when we have auto-complete, and [23:08] also limits us with the content access syntax [23:09] But instead of taking it as either / or. Are there adjustments to the current syntax that could make it better? The two of you will never agree 100%. [23:10] When you come with two different starting points then the agreement has to be something between - or a mix. or one follows the majority and gets a few adjustments. [23:10] form.Firstname='Emma' is as easy to type and rember as Firstname='Emma' [23:11] Here both of my users barfed. And so do I. [23:11] the former one is required to have a clearly defined syntax for auto-complete and content access syntax [23:11] anyway, i will not insist on this [23:11] just pointing out that this shortcut will limit us in the future [23:12] But our users will love it I can assure you. And you will not need a search generator for these simple cases. [23:12] So a search editor could simply just always assume the full syntax [23:12] it shouldn't, becasue the semantics are clearly defined. If there is a key field called 'Firstname', it will take precedence, and the query has to use form.Firstname to disambiguate. [23:12] Lavr__: right [23:13] it is probably also slower since the code needs to do the disambiguation at run time [23:13] To those that do not have seen the doc page. See http://merlin.lavrsen.dk/twiki/bin/view/TWiki/QuerySearch [23:13] anyway, i will not stand in the way [23:14] the other pont is the x[query] syntax [23:14] although powerful, i feel that this will limit us in the future [23:14] slower? perhaps. The implementation is there in SVN if you want to investigate that. [23:15] and is very high on the geek factor [23:16] My concern is that there is a X[query], X.Y and X/Y syntax. I am personally not 100% sure how that works based on the doc. Especially the X/Y syntax is "special". [23:16] time check: +75 min [23:16] it's that way so the syntax can be context free [23:16] But if it gives the advanced users some power in future then I can live with it. [23:16] the counter argument is to do one step at a time [23:17] let users get familiar with new new query syntax [23:17] and build upon it later [23:17] nobody screams for the complex ueries [23:17] I think that point was covered in the topic on Codev [23:17] those that do can use the formqueryplugin now [23:18] but it looks like crawford wants to have the complex feature in 4.2 [23:18] Some do. One of my users was looking for searching for topics saved between two dates for example. But he is a real power search user already. [23:18] well, I think I already made the point that without the complex queries, the query language is pointless [23:18] We have both kind of users. The pointy haired bosses and secretaries and the total geeks. [23:18] you might as well use word search [23:19] releasing a query language that was brain dead would just piss peolpe off [23:19] I think we now have a syntax with a NerdoMeter level 2 mode and a NerdoMeter 6 mode. [23:19] especially when they already have much more powerful plugins [23:19] Peter, Crawfor and I take all the time. Anyone else with comments? [23:20] can we decide on what is in, what should change on the syntax? [23:21] If we want this feature at all we need to give Crawford time to optimize. [23:21] But we can take the option to declare part of the syntax experimental and reserve the right to change it [23:21] But it should then only be a small part. [23:22] Arthur - a statement from you? [23:23] Steve? Mr Customers representative ;-) [23:23] Lavr__: that sounds like a rational approach, if there really is such a high level of discomfort. [23:23] i suggest to leave the comlex syntax in 4.2., but to leave it undocumented so that we can change it in the next production release if needed [23:23] I don't think the syntax is a problem if we have enough examples [23:24] I really don;t want to undocument what I already documented. [23:24] it is easier than the regex queries we have now [23:24] I don't mind tagging sections of it experimental, but leaving it undocumented..... bleagh [23:24] svn helps you recover undocumented stuff [23:24] in SearchPatternCookbook [23:24] I think the idea to document - also with examples - and put the things we worry about marked as experimental is a good idea. That also gives us market feedback. [23:25] At least in the beta phase we need to get the feedback. [23:26] speaking of which... [23:27] it would help if I knew which sections of the syntax are supposed to be experimental. attachments[name="*.gif' AND size.1024], I presume? [23:27] we need some mad users with running installations to do the testing on a live site [23:27] Yes. That is the idea with beta testers. [23:28] I am not sure about making things experimental when I actually might want the stuff in add-onds [23:28] Maybe if we can find beta testers in our near environment where we can offer to go and help installing and then go back for feedback. [23:28] i think x[query] and x/y are experimental [23:29] parent.name/(form.name='ExampleForm') looks may too comlex for average user [23:29] Let us start from a working model that .... [23:29] parent.name.form.name='ExampleForm' looks much simpler [23:29] .. all is documented. [23:29] fell, FQP survived without x/y for two years, so I guess it *is* experimental - we've only had it for a year. [23:30] ... X[query] and x/y is experimental and marked as such. [23:30] And then based on beta test feedback we can decide what we keep experimental and what we make "released" [23:30] also, i do not see a reason why we need a META:TOPICINFO.something _and_ a info.something [23:30] I honestly don;t think average users will use anything more complex than Firstname='Fred'. The / is really power-user stuff. [23:30] skip the geeky internal name [23:31] PeterThoeny: that was driven by the desire to make it familiar to people moving from RE searches [23:31] they already know about that stuff, and it's widely documented [23:31] The "geek" names are geek. But they enable searching for metas unique to plugins [23:31] that too. [23:32] We can always emphasize on the easy names and document the geek as a generic alternative that can search for any meta data [23:33] We will for sure rewrite the QuerySearch topic a couple of times before we release. [23:33] if there is a META:FOOBAR{ ...}, a simple and intuitive syntax is meta.foobar.name='sushi' [23:33] And add an example cookbook topic [23:33] thsi is kiss [23:34] but we can hide that from 4.2 if needed [23:34] Peter, we've been through this before; do yu really want to go through it all again here? [23:34] But if there is a META::KennethLovesWomen then ...??? [23:34] I think I gave reasons why that syntax is ambiguous several times [23:34] meta.kennethloveswoman [23:34] and it's late in the evening [23:35] I think we have enough to continue on on this one. [23:35] That was the only open proposal. From now on this agenda point should change to - walkthrough of urgent bug items. [23:36] at least this is what i would like to get out of this meeting: decide what to cut where we do not find an agreement, and decide what to hide/label as experimental for experimental stuff [23:36] I don't feel like recursion today [23:36] (my client's pretty slow now) [23:36] (don't bother) [23:37] My proposal before was.... we start with X[] and X/Y marked as experimental very clearly. [23:37] yes, but instead of experimental, i would undocument it [23:37] And then decide again during beta test period based on customer feedback. [23:37] You do not get feedback from hiding it. [23:37] ok, good point [23:38] mark as experimental during beta, with note that this feature might get removed in 4.2 [23:39] can we agree on this? [23:39] Yes. That gives Crawford the peace now to focus on making the search work faster for at least the simple cases. And we can make much better decision when we have customer feedback. [23:39] Agreed. [23:39] ok [23:39] great. Thanks [23:39] ---+ 4. Coordinate TWiki Release 4.2 [23:40] # Desired outcome: Decide on tentative dates for string freeze and other dates [23:40] what is the timing of string freeze and beta start date? [23:41] i assume first beta, than rc [23:41] than string freeze [23:41] ? [23:41] string freeze two weeks before production [23:41] We have beta release 17 June but I do not believe this anymore because that required that Sven was 100% done and everybody working 100% on bugs only [23:41] doesn't that rather depend on clearing the bug DB first? [23:41] suggestion: no beta until the bug DB has *no* bugs in New status, Normal or above [23:42] everything must at least be confirmed, and signed of by Ken [23:42] Good goal. I can buy that. [23:42] as ok to release without a fix [23:42] ambitious [23:42] you think? I'm not asking for fixes, just for analysis [23:43] i find it too ambitious [23:43] ok [23:43] we have so many bugs that will take us a long time to fix [23:43] this has bitten us before; we release 4.1 with open, unanalysed bugs, and they came back and bit us [23:43] precious time we could use in parallel for beta tester feedback [23:43] as i said, I'm not asking for fixes, just for analysis [23:43] It is easy to get bugs to zero. If we stop testing. But we will find at least 200 bugs before we release - is my wild guess. [23:44] yes [23:44] there is no point in just adding bugs that will never get fixed [23:44] We have ONE bug group that I am concerned about in 4.2.0 because we lack someone to drive it. In one word [23:44] I18N [23:44] we need to eat the snake from both ends [23:45] Lavr__: agreed [23:46] We really need to recruit someone with a real interest to work on those. [23:46] i need to sign off now [23:46] Some russian guy or something [23:46] will leave the log rolling [23:46] if possible please decide on adjusted beta release date [23:46] SO! On dates. The xtal ball says. beta probably not until mid July. [23:46] Lavr__: Russia, Chinese, Bulgarian! Hey, Will! Bulgarian! [23:47] mid July? hmmm [23:47] Which is summer vacation :-( [23:47] I am very busy between now and then, but I will try [23:48] We will all work on the bugs [23:48] but it really depends on other people pitching in and helping with the analysis/re-rating of the bugs [23:48] As long as we all agree to maintain the feature freeze and not release crap then I am still optimistic even if I bark all the time. [23:48] because i really don't believe all those are really bugs [23:48] There are many reports where reproduction is an issue [23:49] Lavr__: no problem. BTW I already have aplugin in the pipeline for the search summary keyword highlighting [23:49] does it make a new summary as well? [23:49] Lavr__: YES. it often takes as long to build a testcase to reproduce a problem as it does to fix it [23:50] ArthurClemens: yep [23:50] nice [23:50] ArthurClemens: if it works ;-) [23:50] which is also why we so much need d.t.o back on its feet. [23:50] it is a good incentive to add testcases [23:50] you saw I pushed the testcases web into the unit test runs? [23:50] sorry, it makes the unit tests very slow [23:51] didn't touch it yet [23:51] You got a Twiki heart for that. [23:51] did I? ooooh - thanks! [23:51] but the testcases web mainly has visual tests [23:51] actually, it has a lot of auto tests too [23:51] and those are the ones I pulled in [23:52] anyway, here's how I see things: [23:52] Many have problems making real hard core Perl unit test cases. But it is easy to make a small auto test case in the TestCases web so many this will make more make test cases this way [23:53] s/many/maybe [23:53] heh. I'll believe it when I see it [23:53] I put a huge amount of effort into that framework, and the people who asked for it have never used it. [23:54] anyway, let's get this straight: top priority for dev is the users code [23:54] I did some test cases very early. And I plan to make more in the TestCases web. I have run them 100s of times when I was close to release. [23:54] second prio is performance of queries [23:54] I have to log off, still a lot of homework to do before tomorrow [23:54] top prio for skins etc is bugs, and performance [23:54] ciao, Arthur [23:55] (maybe I should start doing freelance, sigh) [23:55] g'night [23:55] ArthurClemens: there's no money in it :-( [23:55] yes. Agree. Arthur you also have a few Pattern bugs that have been hanging around for quite some time in the urgent list. [23:56] in the bugs web; chase people for feedback, and convert New bugs to Confirmed (if they can be reproduced) [23:56] with the goal of a clean sheet before the beta [23:56] Yep. [23:57] * ArthurClemens has quit IRC [23:57] when I have finished optiising I will be back on fixing duty, as and when i get time [23:57] YOU CDOT always do more than your duty on the bug fixing side. [23:57] actually, if I was part of a team, you wouldn't even notice [23:58] the rotten strawberry is always on the top of the cream :-( [23:58] I know what you mean. [23:59] but, life being what it is, we must plough on. Perhaps Peter will fix a bug or two as well. [23:59] OK. I finish minutes tomorrow which is our constitution day so I have most of the day off. And my wife is at work so - free to do some twiki. [23:59] Lavr__: I think we are the only ones left, and I'm signing off, so..... Session Time: Tue Jun 05 00:00:00 2007 [00:00] Good night. [00:00] and you [00:00] * CDot has left #twiki_release [00:00] actually, I was kind of still hanging around watching :-) [00:01] Today was a very good meeting. [00:01] I am punching out also. [00:01] looks like you guys got alot done -- wikiring is still non-responsive [00:02] it is a bot [00:02] and I am leaving too. ciao Session Close: Tue Jun 05 00:02:23 2007