All times listed are Mountain Standard Time (GMT-7)

14:00:53 <Lynnwood>	Shall we just jump into the meeting on time?
14:00:53 <ArthurClemens>	its 22:00
14:01:07 <Lynnwood>	sorry arthur - pre-meeting chat.
14:01:11 <ArthurClemens>	a ok
14:01:38 <PeterThoeny>	lynnwood: yes, any discussion on spec should be done in codev
14:01:39 <PeterThoeny>	crawford is missing
14:01:41 <PeterThoeny>	shall we give it a few minutes?
14:01:53 *	SvenDowideit_ (n=sven@203-166-246-247.dyn.iinet.net.au) has joined #twiki_edinburgh
14:02:18 <Lynnwood>	I suggest not unless we come up to a topic he _has_ to provide input. Everyone knew the start time.
14:02:33 <Lynnwood>	Steffen - will you be taking notes again?
14:02:39 <SteffenPoulsen>	yep
14:02:43 <PeterThoeny>	ok, then, shall we start?
14:02:51 <PeterThoeny>	thanks steffen :-)
14:02:55 <Lynnwood>	let's...
14:03:08 <PeterThoeny>	them minutes are at http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x02x20
14:03:20 <Lynnwood>	but not the agenda.
14:03:26 *	Lynnwood going back to email
14:03:37 *	AndreU has quit (Read error: 104 (Connection reset by peer))
14:03:43 <PeterThoeny>	yes, with the proposed agenda
14:03:57 <SteffenPoulsen>	Lynnwood: Very short agenda this time :-)
14:04:07 <PeterThoeny>	on purpose :-)
14:04:10 <Lynnwood>	short and thick
14:04:26 <wbniv>	i'd like to bring up the tinderbox issues now that it's post-Dakar
14:04:50 <wbniv>	but i'll wait my turn :)
14:05:04 <PeterThoeny>	ok, lets add that as item 3
14:05:08 <Lynnwood>	any other proposed agenda items?
14:05:22 <Lynnwood>	Does sequence look good?
14:05:39 <Lavr>	The large backlog of bugs I assume will be discussed under 4.0.2
14:05:44 <Lynnwood>	hearing no other additions, lets jump in.
14:05:54 <Lynnwood>	let's address it there.
14:05:57 <PeterThoeny>	http://develop.twiki.org/~develop/cgi-bin/view/Bugs/AllOutStandingItems lists too many items
14:06:11 *	CDot (n=crawford@crawfordcurrie.plus.com) has joined #twiki_edinburgh
14:06:12 <PeterThoeny>	is there a report that shows just the urgent + required ones for 4.0.2?
14:06:43 <Lynnwood>	Perhaps we have agreement of urgency level to include in 4.0.2?
14:07:11 <Lavr>	I personally do not mark things urgent to get them into 4.0.2. There are many "normal" bugs that should get attention.
14:07:26 <SteffenPoulsen>	(summary on #s are Requirement: 5, Urgent: 5, Normal: 35, Low: 16)
14:07:49 <Lavr>	Is that the true number?
14:08:16 <wbniv>	Lavr: then requirement would be it, right?
14:08:18 <Lavr>	Sometimes the searches limits to 99 and hide many
14:08:23 <wbniv>	urgent is for things that need to be fixed asap
14:08:33 <Lynnwood>	perhaps then agreement to at least address all urgent and then as many normals as can be.
14:08:33 <PeterThoeny>	The AllOutStandingItems lists: Low: 26
14:08:34 <PeterThoeny>	Normal: 67
14:08:34 <PeterThoeny>	Requirement: 8
14:08:34 <PeterThoeny>	Urgent: 10
14:09:15 <PeterThoeny>	well, it is good to have as many "normal" ones fixed as possible,
14:09:38 <PeterThoeny>	the question is do the "urgent" and "required" ones require an asap release?
14:10:04 <CDot>	they require a release to be done when they are cleared, yes
14:10:11 <CDot>	otherwise you lose momentium
14:10:28 <CDot>	keep the energy going
14:10:41 <Lynnwood>	makes sense but this has not been clarified on bugs web.
14:10:57 <PeterThoeny>	to answer this question i suggest that we scan the urgent and required ones for 4.0.2 applicability
14:11:29 <SteffenPoulsen>	hmm, I'm confused .. why do we get different numbers - is the link in webleftbar (Items by urgency) filtered too much?
14:11:49 <Lynnwood>	OK - noting this could take a while
14:11:55 <Lavr>	The problem at the moment is that more bugs are opened than closed. Because people think Edinburgh more than getting Dakar stable.
14:12:27 <PeterThoeny>	crawford undeferred many items for edinburgh, hence many "normal" ones
14:12:43 <CDot>	right
14:12:46 <PeterThoeny>	we need a way to distinguish edinburgh items and 4.0.2 items
14:13:00 <CDot>	also right
14:13:09 <Lynnwood>	Looks like this is developing into more involved discussion - i.e. clarifying meaning/function of bug priority settings
14:13:26 <CDot>	I have been making a judgement call, and marking some as "merge to 4.0.2" as I fix them
14:13:39 <PeterThoeny>	sven added the "mergeto" form field
14:13:58 <PeterThoeny>	sven: at what time do you suggest people check the 4.0.2 box?
14:14:03 <Lynnwood>	as peter proposed - for now, shall we run through the list and just mark for 4.0.2 if we can avoid getting into detail on each.
14:14:08 <Lynnwood>	?
14:14:09 <CDot>	yes
14:14:13 <PeterThoeny>	at time of bug submit or time of fix?
14:14:14 <CDot>	go for it
14:14:34 <Lynnwood>	I'm working off "Items by urgency" list
14:14:42 <PeterThoeny>	ok
14:14:56 <Lynnwood>	OK 
14:14:58 <Lynnwood>	Item1605 	 RCS (cygwin) or twiki apply permission on file with READ and not WRITE
14:15:00 <Lavr>	Be careful with some searches. They have a limit of how many they show.
14:15:21 <Lynnwood>	Lavr - could you see if we're missing critical items using this list?
14:15:31 <Lynnwood>	it just seems the best to work with for now.
14:16:25 <Lynnwood>	item 1605 - include in 4.0.2. ?
14:16:29 <Lavr>	AllOutStandingItems has no limit in the search so it is a good one to use.
14:16:34 <SteffenPoulsen>	Lavr: the items by urgency search is OK, no unwanted exclusions
14:16:51 <Lynnwood>	Or can we say all the urgent items should be included and move to normal?
14:17:04 <Lavr>	I removed the limit of one of them some days ago. Probably that one Steffen
14:17:06 <SteffenPoulsen>	AllOutStandingItems takes in the extensions, by urgency leaves them out
14:17:14 <SteffenPoulsen>	Lavr: ok
14:17:48 <Lynnwood>	I'm seeing 5 urgent items - should and CAN all these items be addressed in reasonable timeframe?
14:17:50 <SteffenPoulsen>	no opinion on 1605 from me, can't reproduce
14:17:52 <Lavr>	The extensions ones are often equally important. Many bugs related to for example TablePlugin and EditTablePlugin.
14:18:04 *	SvenDowideit has quit (Success)
14:18:21 *	Soronthar has quit (Connection timed out)
14:18:23 <Lynnwood>	Sven has interesting measure of success ;-)
14:18:42 <Lavr>	I can change status of some to urgent if that is what it takes to get them resolved. If normal means ignore we may as well remove that selection.
14:19:15 <Lynnwood>	I'm hoping to dispense with the current urgent list since I figure more discussion will be needed on the normal list.
14:19:22 <wbniv>	no, that's not what it means and please don't abuse the priority
14:19:27 <SteffenPoulsen>	1605: But others are reporting the same issue in Support web, so it would be great if someone with a Windows setup would look into it
14:19:28 <Lavr>	I mark those bugs "urgent" where I "urgently" need the fix and cannot wait for next release.
14:19:31 <wbniv>	otherwise they *will* become meaningless
14:20:08 <Lynnwood>	OK. if I follow you wbniv - do you want to discuss each of the urgent items?
14:20:22 <CDot>	Lavr: that's right; you work off the SVN, so that's how I interpret your requests
14:20:36 <CDot>	you need it now, means to me "it must go in 4.0.2"
14:20:43 <CDot>	seems simple enough
14:20:51 <Lynnwood>	so it seemed to me.
14:21:02 <SteffenPoulsen>	I use the same interpret
14:21:24 <Lavr>	Then I may have to re-evaluate a few.
14:21:26 <Lynnwood>	is there any reason why any of the urgent items should or can not be included in 4.0.2?
14:21:44 *	bitca (n=Meredith@proxy.wildwoodweb.net) has joined #twiki_edinburgh
14:21:45 <CDot>	yes
14:21:51 <SteffenPoulsen>	no-one interested in solving bugs are on Windows, showstopper for 1605
14:21:58 <bitca>	lol
14:22:09 <CDot>	I have not been distinguishing "urgent for edin" and "urgent for 4.0.2
14:22:12 <Lavr>	The mod_perl issue is marked as urgent but until we find a root cause and fix it cannot go into 4.0.2. And not resolving it should not gate 4.0.2 IMHO
14:22:33 <PeterThoeny>	true
14:22:49 <CDot>	SteffenPoulsen: did anyone ask the reporter of 1605 if they tried changing the default file permissions?
14:23:13 <Lynnwood>	OK, we've noted limitation/ambiguity of current priority system. 
14:23:16 <CDot>	I have Windows, but I use IndigoPerl => no cygwin => no permissions problems
14:23:26 <SteffenPoulsen>	I think there was more roundtrip in the Support. report, but I haven't been doing any follow up
14:23:52 <CDot>	well, things have to remain marked as serious until someone follows up
14:24:04 *	Lavr is still trying to look up 1605. Bugs is slow.
14:24:27 <bitca>	You mean bugs are slow. A bug is slow
14:25:04 <SteffenPoulsen>	yap, richard commented on http://twiki.org/cgi-bin/view/Support/CVSAndMailProblems
14:25:13 <wbniv>	bitca: he means the Bugs web is slow
14:25:13 *	AndreU (n=AndreU@c-180-216-51.cvx-h.dial.de.ignite.net) has joined #twiki_edinburgh
14:25:16 <SteffenPoulsen>	I'll add a link to 1605
14:25:35 <Lavr>	I have it now. :-)
14:25:37 <Lynnwood>	So... let's see - we can use the "Merge to" field to tag items to include.
14:25:42 <Lynnwood>	as it was meant...
14:25:48 <CDot>	right
14:26:14 <PeterThoeny>	so the idea is to tag as 4.0.2 at the time of bug submit, right?
14:26:16 <PeterThoeny>	not fix?
14:26:19 <Lavr>	I understood that it was when it was fixed that you tagged it.
14:26:32 <CDot>	the field had no explanation
14:26:38 <CDot>	but that is how I have been using it
14:26:44 <CDot>	i.e. fix => mark
14:26:57 <CDot>	I would prefer to have them marked up-front though
14:27:04 <PeterThoeny>	there is also a need to tag at time of bug submission
14:27:06 <CDot>	so that a priority order can be established
14:27:09 <Lynnwood>	for now, can we use it to note what we want in 4.0.2 - lacking a better mechanim
14:27:14 <Lynnwood>	?
14:27:15 <CDot>	please
14:27:24 <PeterThoeny>	any disadvantage of tagging it early?
14:27:32 <CDot>	no
14:27:35 <PeterThoeny>	if not lets tag 4.0.2 at time of submission
14:27:37 <PeterThoeny>	ok
14:27:54 <Lynnwood>	ok - then let's start again from top.
14:28:01 <CDot>	top?
14:28:05 <Lynnwood>	I heard NO for 1605 for 4.0.2.
14:28:26 <Lynnwood>	meaning top of item list by urgency.
14:28:48 <Lavr>	List by urgentcy has extentions?
14:28:57 <PeterThoeny>	---+ Item1610 Configure script corrupts NameFilter? (Unmatched Bracket in Regex)
14:29:12 <PeterThoeny>	is the next one
14:29:13 <CDot>	Lavr: extensions included iun the release, yes
14:29:18 <CDot>	other extensions, no
14:29:46 <Lavr>	What I mean is that the search will not show ANY.
14:29:58 <Lynnwood>	I encourage us to stick to short discussion or whether or not to include in 4.0.2 - NOT going into any detailed discussion on solving each.
14:30:01 <CDot>	1610 must be ticked
14:30:15 <Lynnwood>	OK. if now objections then next...
14:30:26 <Lynnwood>	s/now/no
14:30:37 <CDot>	next?
14:30:47 <Lynnwood>	Item450 -  	 View requires %TEXT% to be in template
14:30:50 <CDot>	no tick
14:30:58 <PeterThoeny>	ok, i just marked 1610 as 4.0.2
14:31:08 <CDot>	450 is Edin only
14:31:12 <Lynnwood>	OK
14:31:21 <Lynnwood>	Item1576 	 Saving topic often fails when mod_perl is enabled.
14:31:35 <CDot>	if it can be reproduced, then tick
14:31:39 <PeterThoeny>	on 1610, is anyone looking into this?
14:31:46 <Lavr>	No. Would like more help to find root cause.
14:31:55 *	CDot now has 6 sites running mod_perl with twiki and hasn't seen the problem yet
14:31:59 <PeterThoeny>	because the workaround is a potential security hole by omitting " from the filter
14:32:01 <Lavr>	We should remove the mod_perl from release notes until fixed.
14:32:28 <SteffenPoulsen>	PeterThoeny: A workaround is also simply deleting it, the default set in TWiki.cfg will take precedence then
14:32:43 <CDot>	PeterThoeny: the fix is to make configure handle quotes more smartly, something that isn't hard to do, but I just haven't had time
14:32:55 <PeterThoeny>	steffen: i tried that, it gets copied bck in as corrupt
14:33:06 <CDot>	if someone wants to look at it before I get there, they are very welcome
14:33:28 <Lynnwood>	CDot has already suggested that this get included. Any objections?
14:33:44 <PeterThoeny>	seems like some perl versions grok 'foo"bar' and some not
14:33:47 *	SvenDowideit (n=sven@203-217-85-207.dyn.iinet.net.au) has joined #twiki_edinburgh
14:34:00 <CDot>	timeout. next?
14:34:11 <Lynnwood>	Again - let's not get into detail on each item unless necessary to determine whether to include in 4.0.2
14:34:28 <Lynnwood>	Item1629 	 patchfile for TWiki 4x0x1 renders my installation unusable
14:34:49 <Lynnwood>	(not very helpful summary...)
14:35:07 <bitca>	Interesting question as to how to include in 4.0.2
14:35:19 <SvenDowideit>	moring guys - sorry bout that slept late - and my link is tryly stuffed
14:35:25 <bitca>	Should inclusion mean rendering installation of 4.0.2 unusable?
14:35:31 <CDot>	SvenDowideit: excuses, excuses
14:35:47 <Lavr>	Seems to be either a build problem or a support type problem.
14:36:03 <wbniv>	this sounds like a 4.0.1-specific problem, and isn't relevant to 4.0.2
14:36:06 <wbniv>	*except*
14:36:16 <PeterThoeny>	i would reprioritize 1629 as normal
14:36:17 <bitca>	nary a chuckle
14:36:25 <CDot>	PeterThoeny: agreed
14:36:27 <wbniv>	unless it's related to the build process for producing patch files in general
14:36:30 <Lavr>	Agree
14:36:42 <Lynnwood>	sold! let's move on.
14:36:46 <SteffenPoulsen>	SvenDowideit: Any opinion on http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1629 - should build procedure be adjusted before 4.0.2?
14:36:46 <CDot>	next?
14:36:55 <wbniv>	actually, sounds like urgent, but not related to 4.0.2 to me
14:36:58 <wbniv>	but whatever
14:37:04 <Lynnwood>	Item1682 	 Need a way to modify permissions
14:37:05 <SvenDowideit>	build procedure?
14:37:13 <CDot>	1682 no tick
14:37:15 <SteffenPoulsen>	or patch-build
14:37:16 <Lynnwood>	this is the first "requirement" time.
14:37:21 <Lynnwood>	item
14:37:24 <CDot>	1682 no tick
14:37:29 <SteffenPoulsen>	or is it just error 40 all the way?
14:38:07 <Lynnwood>	I'd encourage folks to vote on an item quickly - even if you need more time to formulate your reason.
14:38:10 <CDot>	what about the other urgents? 1560 for example?
14:38:11 <bitca>	CDot, CDot rah rah rah
14:38:20 <Lynnwood>	Otherwise I'll move on briskly.
14:38:32 <Lavr>	It takes TIME to look up the bug report Lynnwood. A number says nothing.
14:38:55 <Lynnwood>	understood. I'll give more time.
14:39:07 <Lynnwood>	did I miss some urgents?
14:39:21 <CDot>	1560 should be ticked
14:39:32 <bitca>	I don't even *see* a 1560
14:39:36 <Lavr>	You miss the ones that are extensions such a PatternSkin
14:39:40 <Lynnwood>	I don't either.
14:40:05 <bitca>	Must be a Mac thing
14:40:06 <Lynnwood>	does anyone have a url for list we can all work off of?
14:40:14 <Lavr>	By urgentcy skips too many 
14:40:15 <CDot>	look at AllOutSTandingItems, sort on priority
14:40:24 <Lynnwood>	OK. thanks
14:40:25 <PeterThoeny>	to avoid confusion, can we proceed first with the list lynnwood suggested
14:40:43 <CDot>	Lynnwood: http://develop.twiki.org/users/develop/cgi-bin/view/Bugs/AllOutStandingItems?sortcol=3;table=1;up=0#sorted_table
14:41:07 <Lynnwood>	let's use this new url - as long as we're all on same page.
14:41:09 <SteffenPoulsen>	I'll set Item1629 as an action item for Sven, to decide whether this is related to the offered file or the procedure executed by the reporter
14:42:00 <bitca>	When in doubt, dump on Sven?
14:42:07 <SvenDowideit>	y - though i do think its operator error
14:42:13 <SvenDowideit>	god i hope so :)
14:42:21 <CDot>	Lynnwood: on that list (the url I posted) we are on 602 (applies to shipped skins) and we skipped 1342
14:42:29 <CDot>	apart from that you have hit everything
14:42:36 <Lynnwood>	thanks CDot - I'm still loading.
14:42:52 <Lynnwood>	veeerrry sloooowly
14:43:00 *	Soronthar (n=Sorontha@200.7.110.244) has joined #twiki_edinburgh
14:43:02 <CDot>	anyway, 1342: I18N on WysiwygPlugin, no tick IMHO.
14:43:47 <CDot>	602 - no tick
14:44:04 <CDot>	548 - no tick
14:44:15 <bitca>	I haven't managed to load at all yet
14:44:25 <CDot>	1634 - tick
14:44:40 <CDot>	1349 - no tick
14:44:44 <Lynnwood>	I'd encourage folks to follow CDot's example and just weigh in on any of them and then we'll revisit any where some disagreement arizes.
14:45:11 <SvenDowideit>	i'm happy to agree with CDot, and use the meeting for somethgin else
14:45:14 <CDot>	1649 - hanging in space, I will defer to Lavr's opinion
14:45:23 <PeterThoeny>	yes, Item1634 definitely needs a tick (Pattern Skin in Dakar: verbatim text and large images makes everything wider than the screen)
14:45:27 <CDot>	1670 - no tick
14:45:32 <wbniv>	1649 tick
14:45:40 <Lavr>	1649 - I still need to find root cause. If we can live with version 1.20 that one cause no trouble
14:45:40 <CDot>	1682 - no tick
14:45:57 <Lavr>	I will talk to Arthur about that.
14:46:02 <CDot>	Lavr: 1649 - excellent, so we tick then?
14:46:12 <Lavr>	For now yes.
14:46:15 <SvenDowideit>	other stuff that needs ticking - the things that have been closed since 4.0.1
14:46:17 <CDot>	1684 - no tick
14:46:20 <ArthurClemens>	that means we cannot upgrade
14:46:37 <ArthurClemens>	1649
14:46:44 <CDot>	ArthurClemens: if upgrading means that IE breaks, then no, we can't upgrade
14:47:01 <ArthurClemens>	generally it does not break IE
14:47:22 <ArthurClemens>	but Lavr has 4 colleages with extensions on their computer
14:47:23 <Lavr>	Arthur - let us discuss that afterwards. Maybe we can find the root cause while you continue on the Pattern Skin.
14:47:43 <ArthurClemens>	we can ship the first next release with 1.20
14:47:48 <ArthurClemens>	and then move on to 1.5
14:47:58 <CDot>	Note that I am assuming that *only* the checkins associated with the ticked issues will be mnerged to 4.0.2
14:47:59 <ArthurClemens>	I mean dot dot release
14:48:00 *	SvenDowideit_ has quit (Connection timed out)
14:48:26 <wbniv>	CDot: that's how it should be, yes
14:48:27 <CDot>	there is other checked-in code on DEVELOP branch that should *not* be merged
14:48:30 <Lavr>	If 1.2 has the functions you need we should do that fof 4.0.2 and I will continue finding out why.
14:49:08 <ArthurClemens>	agreed
14:49:19 <SvenDowideit>	yes, the only things i will merge over are the ticked itest
14:49:23 <SvenDowideit>	items
14:49:40 <SvenDowideit>	and even then, only the ones that merge relativly cleanly
14:50:31 <Lynnwood>	I have a concern that going through this entire list is going to take whole meeting and then some.
14:50:44 <Lavr>	I actually upgraded my Motorola installation to HEAD of SVN today. Seems stable.
14:51:17 <CDot>	AFAIK we have finished the list
14:51:27 <CDot>	well, I have ;-)
14:51:33 <Lynnwood>	Oh. 
14:51:37 <Lavr>	Did we do all requirements?
14:51:41 <CDot>	yes
14:51:51 <SteffenPoulsen>	hah - well, we have a shot, debate can follow in Bugs
14:51:55 <CDot>	and all urgents and requirements on extensions
14:52:30 <Lynnwood>	good. OK. perhaps move on to other aspects of 4.0.2 release?
14:52:49 <Lynnwood>	such as... possible timeline?
14:53:33 <Lavr>	1683. I would like that changed to urgent and ticked - if people agree. It is an OPPINION type bug.
14:53:46 <Lavr>	1683 is the ... urls
14:53:55 <SvenDowideit>	ew
14:54:03 <SvenDowideit>	if thats what i think it is, i agree
14:54:07 <Lynnwood>	Are folks OK with SteffenPoulsen's suggestion to take any further discussion on specific items to bugs?
14:54:08 <SvenDowideit>	i did not mean to commit that at all
14:54:30 <bitca>	Sure
14:54:40 <SvenDowideit>	yep
14:54:42 <PeterThoeny>	it defeats the purpose of getting all info on a printed doc
14:54:47 <PeterThoeny>	good in some cases
14:54:57 <PeterThoeny>	should be an option (be able to turn on)
14:55:06 <Lavr>	I would like to control what I see and what I don't.
14:55:14 <CDot>	fine by me
14:55:16 <SvenDowideit>	Lavr, I agree
14:55:17 <PeterThoeny>	yes, with a pref setting
14:55:23 <CDot>	no!
14:55:25 <PeterThoeny>	so it is under the control of individuals
14:55:26 <CDot>	no need
14:55:29 <SvenDowideit>	its not supposed to be there at all
14:55:31 <CDot>	too many prefs settings
14:55:35 <CDot>	keep it simple
14:55:41 <Lynnwood>	I'm sorry - are we talking about 1683?
14:55:44 <SvenDowideit>	its a customer specific change, that is not generic
14:55:44 <CDot>	yes
14:55:47 <SvenDowideit>	(i am)
14:55:54 <Lavr>	I would remove it. If you want a short URL use the [[][]] to show a short URL.
14:55:58 <SvenDowideit>	i'will simply back it out)
14:56:03 <CDot>	done deal
14:56:05 <CDot>	move on
14:56:07 <PeterThoeny>	ok
14:56:11 <wbniv>	it defeats the purpose of getting all info on a printed doc
14:56:25 <CDot>	move on
14:56:28 <Lavr>	I'll urgent and tick
14:56:29 <wbniv>	actually, the lack of the print css from printing the whole url after the link does that
14:56:30 <Lynnwood>	OK. What else do we need to discussion re 4.0.2?
14:56:47 <CDot>	what is on the agenda?
14:56:53 <CDot>	mr chairman ;-)
14:56:59 <wbniv>	because if you have a WikiWord link (for example), it still otherwise doesn't print the whole url
14:57:05 <CDot>	wbniv: shhhhh
14:57:24 <PeterThoeny>	timeline of 4.0.2?
14:57:25 <SteffenPoulsen>	[22:52:47] <Lynnwood> such as... possible timeline?
14:57:28 <wbniv>	CDot: excuse me?
14:58:05 <wbniv>	nevermind, i'll open a new bug
14:58:13 <wbniv>	for the print css stylesheet
14:58:22 <wbniv>	which i'd like to suggest making a 4.0.2 tick
14:58:24 <wbniv>	ok?
14:58:48 <SteffenPoulsen>	wbniv: too technical for me, but please act on it if nescessary
14:59:02 <Lynnwood>	I'm entertaining proposals for timeline...
14:59:04 <SvenDowideit>	timeline - if we can release June-July that whould be good
14:59:07 <Lavr>	By all means - open the bug so we can see what you mean.
14:59:19 *	OliverKrueger has quit ("Chatzilla 0.9.70 [Firefox 1.5.0.1/2006011112]")
14:59:20 <bitca>	Isn't step 5 in the install instructions unnecessary?
14:59:27 <CDot>	hold on; doesn't a timeline kinda assume that people will actually hold to it?
14:59:28 <SvenDowideit>	ie work towards a 6month, smaller feature set releases
14:59:30 <wbniv>	did i not adequately describe it on the exising bug?
14:59:30 <Lynnwood>	I think we're talking about release date for 4.0.2
14:59:31 <PeterThoeny>	sven: i was thinking thsi week or next week
14:59:39 <SvenDowideit>	oh, 4.0.2 - yes
14:59:40 <CDot>	how about releasing 4.0.2 when it's done?
14:59:55 <Lynnwood>	radical proposal from CDot!
15:00:20 <bitca>	If there isn't a deadline, the work will fill the remaining space and time continuum
15:00:30 <CDot>	wrong
15:00:33 <Lavr>	There will be new bugs tomorrow and the day after. I propose we release when the new PatternSkin is ready and we have all had a couple of days to test it and for Arthur to bug fix it.
15:00:36 <CDot>	there is a clear definition of the work
15:00:41 <CDot>	when it is done, it is done
15:00:55 <CDot>	that's what the tick field is for
15:01:01 <CDot>	that's why we prioritise
15:01:06 <bitca>	I was joking. But it does mean focusing on fixing bugs rather than working on what's funner to do
15:01:12 <CDot>	yes
15:01:20 <bitca>	Which, since none of this is mine, is fine.
15:01:23 <CDot>	the sooner it is out of our hair, the better
15:01:26 <Lynnwood>	Yes - my assumption is that we have item list now 
15:01:47 <Lynnwood>	How about Lavr's proposal to wait on next PatternSkin?
15:02:07 <bitca>	The div one?
15:02:11 <CDot>	and bitca, there is no "mine", there is only "ours"
15:02:20 <Lavr>	Arthur you predict Skin ready for testing end of this week right?
15:02:21 *	bitca whistles innocently
15:02:22 <CDot>	if anyone can help someone else out, they should
15:02:29 <CDot>	pleeeeeeeease!
15:02:33 <wbniv>	and sometimes that even happens ;-)
15:02:41 <CDot>	wbniv: right on
15:02:41 <bitca>	I do, don't I? Although I mostly beg for help.
15:02:58 <Lynnwood>	I expect amazing things now that wbniv is back!
15:03:07 <wbniv>	lol
15:03:09 *	bitca does not know this wbniv
15:03:11 *	SvenDowideit_ (n=sven@203-166-246-247.dyn.iinet.net.au) has joined #twiki_edinburgh
15:03:21 *	MichaelDaum has quit (Remote closed the connection)
15:03:35 <wbniv>	first, i want to concentrate on bring back the tinderbox, automated testing and such
15:03:40 <PeterThoeny>	btw, i have a hard deadline at the hour + 30 min
15:03:50 <CDot>	bitca: don't trust him; he's a mexican bandido!
15:03:57 <SteffenPoulsen>	well, how's peoples gut feelings - any time to spare this next fortnight? I know I'll have to go easy on the commitment this next period
15:03:59 <bitca>	I think Arthur can continue to work on PatternSkin and, depending on the state of things, it goes with 4.0.2 or not
15:04:06 <bitca>	Is my opinion
15:04:09 <SvenDowideit_>	i was thinking we release with whatever's fixed at the time
15:04:11 <SvenDowideit_>	but its dependant on at least a few ticked items being fixed
15:04:28 <CDot>	I would prefer to release when nothing is ticked any more
15:04:39 <bitca>	He's making some pretty major changes, so I don't think we should hold up 4.0.2 for it.
15:04:41 <Lavr>	I think no 4.0.2 without the skin. And the time seems right anyway. One week to finish. One week to test and bugfix.
15:04:49 <wbniv>	well, since i am finally back online, i do have a backlog of paid work that i _really_ have to do, but i will have some time for twiki the next two weeks for sure
15:05:05 <bitca>	Depends on Arthur's time estimate, of course. *poke poke*
15:05:09 <PeterThoeny>	crawford: in this case we need some additional way of ticking: must for 4.0.2 and must for the one ofter
15:05:10 <wbniv>	"I would prefer to release when nothing is ticked any more"
15:05:13 <Lavr>	The width problem is the single most severe bug we have currently IMHO.
15:05:26 <CDot>	PeterThoeny: that's fine; add another ticker
15:05:28 <wbniv>	right, the best we can hope for is to set a "we'd _like_ to try and be done by..."
15:05:35 <CDot>	sure
15:05:55 <CDot>	we'd like to be done for (/me stick his finger in the air) Easter
15:05:58 <PeterThoeny>	i would not take it so strickly, e.g. release 4.0.2 if most urgent ones are done
15:06:11 <PeterThoeny>	so the remaining ones get bumped up to 4.0.3
15:06:18 <wbniv>	no, because you can just reclassify those bugs
15:06:27 <bitca>	BTW, div-based pages load much faster
15:06:34 <wbniv>	but the procedure of shipping when all of the ticked items are no longer ticked still holds
15:06:34 <CDot>	wait a mo; you are going to blow away the prioritisation we just did?
15:06:56 <bitca>	I think it's more of "let's see where we are next Monday and decide"
15:06:57 <CDot>	if we want to bump things, we need to bump them *now*
15:06:59 <Lynnwood>	Given the complexity and scope of anticipated PatternSkin changes, I'd have hesitation about sticking it in new release on short notice.
15:07:01 <wbniv>	hold on cdot, i think bug prioitisations are open to change later on
15:07:06 <CDot>	so we don;t waste time working on them
15:07:10 <Lavr>	Two weeks from now seems like the right target to me. We can always pick up more bugs in a 4.0.3. Remember. Tomorrow more bugs that may need to be "ticked".
15:07:26 <wbniv>	2 weeks is a good timeframe to shoot for, yes
15:07:35 <CDot>	so be it
15:07:41 <bitca>	Make it so
15:07:45 <CDot>	amen
15:07:52 <PeterThoeny>	sounds reasonable
15:07:55 <wbniv>	if everything's not done in 2 weeks, then reevaluate the list at that time
15:07:57 <Lynnwood>	I'm hearing possible consensus...
15:08:02 <wbniv>	and possibly defer some
15:08:04 <wbniv>	yes
15:08:07 <CDot>	grab it before it dissolves
15:08:10 <Lynnwood>	any objections - speak or hold peace.
15:08:13 <Lynnwood>	OK
15:08:15 <PeterThoeny>	exactamundo :-)
15:08:22 <Lynnwood>	done.
15:08:24 <CDot>	next?
15:08:33 <CDot>	I want a roadmap
15:08:37 <Lynnwood>	Release focus of EdinburghRelease
15:08:41 <CDot>	I see lots of personal roadmaps
15:08:48 <PeterThoeny>	crawford, we discussed this at length last time
15:08:50 <wbniv>	well, a few anyway
15:08:55 <CDot>	did we?
15:08:55 <PeterThoeny>	see log
15:08:56 <SteffenPoulsen>	it's always a moving target .. what we just did is imho an OK best guesstimate from this point in time, let's put some effort in to prevent to many 4.0.3 ticks
15:09:23 <CDot>	PeterThoeny: last time?
15:09:27 <PeterThoeny>	we decided to first decide on a high level readmap (not into details), then work on the roadmap
15:09:30 <bitca>	Two weeks ago
15:09:34 <PeterThoeny>	(at least that was my understanding)
15:09:36 <CDot>	you mean the meeting I wasn't at?
15:09:43 <Lynnwood>	I have concern about trying to create group roadmap from bunch of individual roadmaps.
15:09:46 <bitca>	Yep, that one
15:09:48 <PeterThoeny>	last meeting of two weeks ago, the one you missed
15:09:49 <CDot>	ok
15:09:51 <SteffenPoulsen>	CDot: good point .. but as you said, no "me" only "us" :-)
15:09:58 <bitca>	=P
15:10:31 <CDot>	Lynnwood: it's the only starting point we have
15:10:33 <bitca>	But this is not communist china!
15:10:39 <CDot>	I would rather see a few customer roadmaps
15:10:47 <CDot>	I'd like to see Lavr's for example
15:10:49 *	SteffenPoulsen hands bitca the right pair of glasses
15:10:55 <bitca>	Some of us are customers. Like me
15:11:05 <CDot>	me too; but non-coding customers
15:11:14 <bitca>	I'm *mostly* non-coding.
15:11:27 <bitca>	Or, rather, I'm making a TWikiApplicaiton
15:11:33 <wbniv>	i'd like to see google's, yahoo!, and novell's!
15:11:37 <CDot>	Meredith, you already wrote a roadmap, so you don;t count any more ;-)
15:11:37 <bitca>	OTOH, Lavr and I are largely on the ame page, I think
15:11:40 <wbniv>	(as well as lavr's ;-) )
15:12:05 <Lavr>	My wishlist is simple. 1. Wysiwyg getting better - especially with tables. 2. performance so I do not get nightmares over how things will run when we have 100000 topics.
15:12:23 <bitca>	Wysiwyg that works on a Mac
15:13:07 <wbniv>	do you mean mac or safari?
15:13:12 <bitca>	Safari
15:13:21 <CDot>	anyway, Lynnwood, are you saying you can't collate a single high level roadmap?
15:13:29 <PeterThoeny>	can we go back to the agenda: high level release focus
15:14:09 <bitca>	Out of the box useability or, at the very least, near-useability
15:14:10 <CDot>	what are you expecting to hear?
15:14:10 <PeterThoeny>	http://twiki.org/cgi-bin/view/Codev/EdinburghRelease#Release_Focus lists some high level items
15:14:16 <Lynnwood>	CDot - no, just that I don't think merging individual roadmaps is shortest route to shared roadmap.
15:14:39 <wbniv>	not merging, but selective picking
15:14:43 <SvenDowideit_>	i agree - its not the shortest, just the most likely to succeed
15:14:44 <wbniv>	(i think is what he wants)
15:14:45 <PeterThoeny>	we should discuss and agree on a _high level_ focus
15:14:47 <Lynnwood>	btw - for now, I'm equating roadmap with Edinburg focus.
15:15:09 <bitca>	Some of us are very interested in CMS
15:15:13 <CDot>	with respect, "focus" usually means "sharp" or "precise", none of which apply to the terms on the EdinburghRelease page :-(
15:15:31 <CDot>	I'd be delighted to focus on customer concerns, if a customer could stand up and express them
15:15:35 <bitca>	Turn the focus ring and things will become fuzzy enough
15:15:35 <PeterThoeny>	my key goal is to focus on customer centric features, and to improve the marketing of twiki.org
15:15:58 <bitca>	I pointed to the wonderful museumconnections website as an example
15:16:07 <Lynnwood>	personally, I'd recommend process whereby we each throw up our 2-4 top desired items for Edinburg and see if we can reach consensus on, say, 10 items.
15:16:11 <wbniv>	#  skins development and consolidation
15:16:11 <wbniv>	# topic object model
15:16:11 <wbniv>	# event triggers
15:16:11 <wbniv>	# gui improvements (AJAX)
15:16:11 <wbniv>	# gui improvements (elision)
15:16:11 <wbniv>	# scalability
15:16:13 <wbniv>	# syndication
15:16:15 <Lynnwood>	and call it whatever we want.
15:16:15 <wbniv>	# plugin component system
15:16:17 <wbniv>	# twiki application bundling (and I18N bundling)
15:16:19 <wbniv>	# wiki patterns cookbook (and/or explanations of wiki patterns used throughout the system docs and/or twiki.org)
15:16:22 <wbniv>	# storage plugin
15:16:24 <wbniv>	# revision control plugin
15:16:26 <wbniv>	# branching/merging/milestoning
15:16:28 <wbniv>	# visualisation
15:16:29 <bitca>	ack
15:16:30 <SvenDowideit_>	wbniv, thats more than 2-4
15:16:41 <SvenDowideit_>	you need to priortise :)
15:16:56 <Lynnwood>	Sven - I mean YOUR 2-4 top ones to START
15:17:00 <CDot>	and justify
15:17:01 <PeterThoeny>	i would not even go into that much details
15:17:11 <wbniv>	1. gui
15:17:13 <wbniv>	2. scalability
15:17:17 <wbniv>	3. syndication
15:17:21 <wbniv>	ok, there's _my_ list
15:17:23 <PeterThoeny>	call it high level focus, or call it high level guidelines
15:17:25 <Lynnwood>	If we all agree on those then expand to next list.
15:17:31 <SvenDowideit_>	1 cms
15:17:38 <SvenDowideit_>	2 simplify 
15:17:45 <SteffenPoulsen>	1. test 2. mod_perl (incl. plugins) 3. wysiwyg
15:17:46 <SvenDowideit_>	3 plugable
15:18:07 *	SvenDowideit has quit (Connection timed out)
15:18:17 <bitca>	CMS features, MUCH better doc, plugin-skin connections
15:18:18 <Lavr>	1 Wysiwyg and 2 Performance = Scalability
15:18:56 <CDot>	1. usability 2. modularity 3. scalability 
15:19:09 <ArthurClemens>	1. relax wikiword syntax
15:19:09 <ArthurClemens>	2. secure attachments
15:19:09 <ArthurClemens>	3. indexing
15:19:21 <PeterThoeny>	mine are:
15:19:21 <PeterThoeny>	1. Focus on customer centric features (e.g. features that help our target audience most) 
15:19:21 <PeterThoeny>	2. Focus on innovation with compatibility in mind 
15:19:21 <PeterThoeny>	3. Strengthen TWiki as an application platform 
15:19:21 <PeterThoeny>	4. Strenthen the marking of twiki.org
15:19:25 <SvenDowideit_>	ew, good point
15:19:42 <SvenDowideit_>	PeterThoeny, none of them are focused
15:19:47 <bitca>	0. Define target audience
15:20:08 <Lynnwood>	Sven - let's hold off critiquing others' brainstorms for now.
15:20:09 <SvenDowideit_>	those are mission things, not direction
15:20:19 <PeterThoeny>	(i have to relocate, will be offline for a few minutes; after hour+30 min i will be on/off spradically since i am leading a session on mashup camp)
15:20:20 <bitca>	-1) Get twiki.org running Dakar
15:20:44 <SvenDowideit_>	-1!!
15:20:56 <SvenDowideit_>	-2 get faster hw for develop
15:21:06 <Lynnwood>	I foresee clarifying/negotiating over list will follow this meeting.
15:21:07 <AndreU>	-3. implement community model for twiki.org
15:21:08 <bitca>	(I'm working backwards off of Peter's list, btw)
15:21:17 <SvenDowideit_>	bitca, y
15:21:51 <bitca>	Prune, prune, prune
15:21:59 <Lynnwood>	What do folks think about using some kind of polling on all items from this brainstorm over next week?
15:22:19 <SvenDowideit_>	yes - thats one thing, 
15:22:21 <CDot>	on the other hand, we could always do what we've always done, and (1) do interesting stuff (2) do useful stuff (3) fix the stuff we break to reduce embarassment.
15:22:25 <Lynnwood>	and then see if we have some consensus items emerge.
15:22:33 <SvenDowideit_>	but please, can people write their personal roadmap topics?
15:22:50 <bitca>	Something we need way way way before Edin (perhaps change to Eden), is moving ancient stuff out of TWiki
15:22:57 <bitca>	(The web, not the product)
15:23:06 <SvenDowideit_>	same fo codev
15:23:16 <CDot>	bitca: you been on the archeological trail?
15:23:32 <CDot>	bitca: or was it palaeontology?
15:23:33 <bitca>	Mostly attempting to find *non* fossils somewhere
15:23:39 <CDot>	:-)
15:23:46 <Lynnwood>	just a thought... but it seems that discussion about reworking TWiki.org is separate topic than features for Edinberg.
15:24:10 <bitca>	Yes, it is. Because it needs to be done BEFORE EDEN!
15:24:16 <CDot>	Edinburra, not Edinberg.
15:24:23 <bitca>	(wasn't EDEN capital of Earth at some point?)
15:24:26 <ArthurClemens>	The difficult thing I find is that I can bring forward ideas, but unless someone picks them up they won't get built
15:24:30 <Lynnwood>	I would propose we start that up as separate on-going dicussion for these sessions.
15:24:50 <ArthurClemens>	Uptill now only the ideas of the programmers are built
15:25:04 <bitca>	Well, I see making TWiki non-terrifying as a major goal, period.
15:25:07 <SvenDowideit_>	ArthurClemens, thats mean :)
15:25:09 <wbniv>	and customers of the programmers, arthur!
15:25:17 <CDot>	hang on a mo. Let's just rewind slightly.
15:25:25 <SvenDowideit_>	we've done lots of things for you that we didn't want :)
15:25:30 <ArthurClemens>	I am overreacting, I know
15:25:36 <SvenDowideit_>	me too :)
15:25:38 *	bitca hesitates to point out that she can write grammatical sentences. At least when she chooses to
15:25:50 <ArthurClemens>	I don't
15:26:00 <Lynnwood>	so noted in the record, bitca ;-)
15:26:05 <wbniv>	ok, cdot, what are we rewinding to?
15:26:11 *	CDot is thinking
15:26:13 <ArthurClemens>	but there is a iny tine bit of truth in it
15:26:16 <bitca>	The point being that mentioning doc is putting myself on the line
15:26:23 <SvenDowideit_>	its a large truth mate
15:26:27 <CDot>	I'm trying to see the best way to proceed
15:26:59 <SvenDowideit_>	bitca, i'm wondering - could you teach some of us?
15:27:01 <bitca>	Having a Howto web will also help steer us to Eden
15:27:17 <SvenDowideit_>	ie be an editor / reviewer 
15:27:17 <CDot>	Peter is banging on about "customer focus" and "marketing", which is fine but not much to do with focusing the Edinburgh release
15:27:34 <bitca>	If we can't write a "How to" do something, then there's a problem
15:27:41 <CDot>	the release needs a simple expression of what we are trying to achieve with it
15:27:50 <Lynnwood>	Here's my proposal: take the brainstormed items for Edinburgh focus and do some polling/discussion over next week to see if some consensus items emerge.
15:28:02 <bitca>	Yes. First of all, you can't focus on customers until you have some vague idea of who they are or who they  might be in the future
15:28:04 <CDot>	they won't, I'll tell you that now
15:28:17 <CDot>	on past performances, you will just get more confused
15:28:39 <bitca>	Second of all, it's bloody embarrassing to have shipped 4.0 without adequate doc and without twiki.org running it
15:28:55 *	PeterThoeny_ (n=PeterTho@207.47.11.5) has joined #twiki_edinburgh
15:29:08 *	bitca crawls back into her cave now that Peter is back
15:29:22 <CDot>	I'd be delighted if we made doc a focus of Edinburra
15:29:28 <SvenDowideit_>	i agree,  it's bloody embarrassing to have shipped 4.0 without adequate doc and without twiki.org running it
15:29:40 <CDot>	even more dleighted if we made TWikiApplications a focus
15:29:52 <PeterThoeny_>	any with shutting out non-developers for doc work
15:29:54 <bitca>	So, apparently I'm going to be solely responsible for Eden?
15:29:58 <CDot>	froze the functionality of the core
15:30:09 <Lynnwood>	is that freeze?
15:30:17 <Lavr>	It is important with customers/marketing people. Do not ask them to define the features. Ask them what they need in "soft" terms. Understand what problems they have in their everyday life and with the current version - and then try to make features that work in that direction. But let the engineers/programmers define the features.
15:30:18 <CDot>	PeterThoeny: huh?
15:30:45 <Lynnwood>	I think we only got part of Peter's comment...
15:30:50 <CDot>	Lynnwood: yes, freeze
15:31:01 <Lavr>	With respect to scalability - customers don't know. Programmers know that performance will suck major when a TWiki grows.
15:31:19 <CDot>	wrong
15:31:24 <CDot>	customers *do* know
15:31:28 <bitca>	OK, so another major goal is to rewrite TWiki into a reasonable language.
15:31:29 <wbniv>	but customers do know they're going to have 1000 pages, or 100,000 or 1,000,000
15:31:32 <CDot>	it is one of the first 5 questions they ask
15:31:46 <wbniv>	bitca: some of us actually like perl
15:31:52 <bitca>	Who?
15:31:54 <wbniv>	bitca: and it's not really going to happen
15:31:59 <Lynnwood>	I'd like to back away from the abstract dicussion about customers, programmers, etc and just see if we _can_ reach some working agreement about focus for Edinburgh.
15:31:59 <wbniv>	besides me?  i'm not sure ;-)
15:32:15 <bitca>	wbniv, I know it's not going to happen.
15:32:17 <CDot>	I suggested one
15:32:19 <wbniv>	bitca: *but* that can be framed in terms of better integration with external services / other languages
15:32:20 <CDot>	doc
15:32:24 <Lavr>	The sys admins know. But the end users do not think about it until things start slowing down.
15:32:26 <CDot>	twikiapplications
15:32:42 <Lynnwood>	yes CDot - so noted. those are good and I suspect there will be support for that.
15:33:02 <wbniv>	that's good, because whenever i try to write a TWikiApplication, i find i have to jump around lots of "features" because the parts don't always fit together well
15:33:05 <Lynnwood>	We have a pretty good brainstorm list here for further discussion and testing for agreement.
15:33:21 <CDot>	oh - there is a third
15:33:22 <wbniv>	and because problems arise when the applications get more complicated
15:33:25 <CDot>	simplification
15:33:36 <wbniv>	esp. as related to using complex statements
15:33:38 <Lynnwood>	yes
15:33:43 <CDot>	I went through configure earlier today and marked 80% of the options as "EXPERT"
15:33:44 <wbniv>	calcs within urlparams within ...
15:33:50 <bitca>	CMS is approximately equal to TWikiApplication
15:34:09 <Lynnwood>	 I'm sorry folks but I'm going to have to bow out now.
15:34:22 <bitca>	Lynnwood, no! You have such good ideas!!
15:34:23 <wbniv>	understood, thanks lynnwood!
15:34:32 <SteffenPoulsen>	well, things could be much worse - imagine if we'd been entirely out of ideas for E :-)
15:34:34 <CDot>	Lynnwood: cya
15:34:38 <SteffenPoulsen>	see you Lynwood
15:34:42 *	bitca notes that she and Lynnwood usually agree on things
15:34:47 <Lynnwood>	I'd be willing to work up a process for polling around the brainstorm items.
15:35:20 <Lavr>	We also have to ensure that TWiki remains a Wiki and be careful we do not fall into the trap and develop TWiki into a webmaster syndrome CMS/Forom thing.
15:35:25 <Lynnwood>	it won't be our current poll feature but a manual process for noting our preference among a longish list.
15:35:29 <CDot>	I think the only thing you can do is set up s straw man and let people take shots
15:35:39 <CDot>	polling is (IMHO) a waste of time
15:35:59 <CDot>	create a straw man, and disallow threaded discussion
15:36:00 <bitca>	But TWiki *isn't* a wiki. It's a huge thing that incorporates wiki features.
15:36:22 <wbniv>	it's (in my mind---supposed to be) an engine
15:36:27 <wbniv>	something that can implement a wiki
15:36:30 <Lavr>	It is a Wiki with a lot of extra very nice features. But we must never loose the Wiki.
15:36:34 <wbniv>	and other typse of web applications as well
15:36:40 <Lynnwood>	I'm thinking of a kind of "dot-vote" process go let folks say "among these 10 statements, I support these 4 the most"
15:37:07 <wbniv>	but right, lavr, we mustn't lose the wiki!
15:37:09 <bitca>	Ah, yes. There are n different voting methods, n fairly large
15:37:10 <Lynnwood>	just a way to check degree of agreement among around a list of times.
15:37:11 *	SvenDowideit (n=sven@203-217-85-207.dyn.iinet.net.au) has joined #twiki_edinburgh
15:37:14 <CDot>	Lynnwood: go ahead and try it, but I really think you have to take a stronger lead on this
15:37:27 <CDot>	from experience, polling just doesn't work
15:37:43 <Lynnwood>	I agree on simple polling as we've implemented it.
15:38:25 <CDot>	you will end up with votes on things that people didn't understand, but it sounded good
15:38:37 <CDot>	"I want one of those. WHat does it do?"
15:38:38 <Lavr>	We will be voting between scalability, less options in configure, blue arrow in corner. It will not lead anywhere.
15:39:27 <SteffenPoulsen>	but what will?
15:39:41 <CDot>	put up a strawman, a set of heads
15:39:48 <CDot>	let people fill in the details
15:40:11 <bitca>	OK, mixing too many metaphors there
15:40:12 <Lavr>	If we just test a few things many proposed. Scalability/Performance. In itself means nothing. The real issue is not IF but HOW.
15:40:13 <ArthurClemens>	In interaction design we use personas for this
15:40:14 *	PeterThoeny has quit (Connection timed out)
15:40:16 <CDot>	e.g. 1. Easier for new users
15:40:20 <ArthurClemens>	Peter has created a topic on that
15:40:40 <CDot>	if you mean EdinburghRelease, it;s too vague
15:40:47 <wbniv>	no, on personas
15:41:04 <CDot>	oh, sorry
15:41:25 <wbniv>	np
15:41:25 <CDot>	Lavr: that is true
15:41:34 *	bitca envisions us with canvas sacks, filling them with straw and then drawing on them
15:41:34 <ArthurClemens>	After the persona is defined, we can say "Ruben needs this"
15:41:37 <Lynnwood>	Well.. gotta go. I'll give it a try this evening or in morning.
15:41:37 <CDot>	any activity needs a leader
15:41:52 <CDot>	bitca: close enough
15:42:09 <SteffenPoulsen>	I wonder what other FOSS projects do in situations like this .. a community pattern with a best practice would be lovely right now
15:42:20 <CDot>	go find out
15:42:21 <ArthurClemens>	The needs are selected through the needs of the persona
15:42:40 <wbniv>	ArthurClemens: personas are great!  sounds like an action item to make some!
15:42:51 <wbniv>	(only 2--4, tho)
15:42:55 <ArthurClemens>	we have to agree to use them as well
15:42:57 *	bitca is just a persona, you know
15:42:58 <Lynnwood>	CDot - if I follow you about "strawman" - my concern there is that we end up with 5 people's strawmen with no process to merge them.
15:43:06 <CDot>	ArthurClemens: the idea is great; the problem with TWiki is that there are as many personas as there are users
15:43:08 <wbniv>	bitca: think archetypes
15:43:17 <wbniv>	(heh, and cdot, too)
15:43:19 <wbniv>	archetypes
15:43:22 <ArthurClemens>	personas are collected user experiences
15:43:24 <CDot>	Lynnwood: no - only one, top level heads written by you
15:43:29 <ArthurClemens>	the manager is one of them
15:43:30 <bitca>	If you google bitca, you'll find out what the archetype is
15:43:32 <CDot>	no alternatives, just refinement
15:43:40 <CDot>	ie. take a lead
15:43:48 <Lavr>	I do not think any persona will resolve the issue "how do we change TWiki so it gets faster and can scale". That is an architectual discussion which should be started.
15:43:52 <bitca>	PHB?
15:43:54 <CDot>	if someone violently disagrees, then they will make it clear
15:43:58 <Lynnwood>	OK - I'll read log of further discussions later this evening. Thanks everyone for bearing with me today.
15:44:03 <CDot>	ciao
15:44:15 <ArthurClemens>	Lavr: not how, but the need
15:44:27 <bitca>	Happily borne
15:44:29 <wbniv>	Lavr: personas aren't about the implememtation
15:44:32 <ArthurClemens>	a persona can tell us it is _very_ important
15:44:38 <wbniv>	they're about *what* to implement
15:44:45 <SteffenPoulsen>	Lavr: are you saying the sysadmin is a non-Persona?
15:44:48 <wbniv>	(kinda, roughly)
15:45:02 <Lavr>	Yes. I agree on the approach but I say it will not resolve an issue like performance.
15:45:14 <wbniv>	go read the personas page (or better yet, go buy all of alan cooper's books ;-) )
15:45:18 <ArthurClemens>	A persona can be stronger than your voice
15:45:24 <bitca>	We're not resolving anything are we?
15:45:29 <Lavr>	Once you have said "TWiki is too slow and cannot cope with many topics" you have a technical issue to resolve.
15:45:55 <bitca>	Which we delegate to the programmers. yay!
15:45:56 <wbniv>	but the persona can say, "i have a lot of data to manage, and i need to manage them quickly"
15:45:57 <ArthurClemens>	you have to define "too slow for what to do what"
15:46:01 <wbniv>	(or something like that)
15:46:51 <wbniv>	(more specific than that, usually, tho, but that's the idea)
15:46:51 <SteffenPoulsen>	I see nothing preventing the sysadmin Persona in uttering this at all .. and a DBA-Persona uttering "it will never scale unless dbms'ed"
15:47:20 <wbniv>	keep in mind, it's important to have only a few personas (typically)
15:47:21 <ArthurClemens>	it might be they turn into one persona
15:47:26 <Lavr>	I think we all know the basic technical problem of TWiki. No indexing of the information makes searching too slow. What I think is needed is two steps..
15:47:36 <Lavr>	1. Agree performance is in Edinburgh
15:47:47 <bitca>	Performance is an easy item. We all want more performance. Who the hell ever wanted less performance?
15:47:51 <ArthurClemens>	this way nothing will change
15:47:52 <Lavr>	2. Start discussing how to rearchitecture TWiki
15:48:00 *	SvenDowideit_ has quit (Connection timed out)
15:48:07 <wbniv>	ok, i'll agree to #1; it should always be an item
15:48:20 <wbniv>	but those are completely different discussions as to what the user interaction is
15:48:21 <wbniv>	...
15:48:24 <wbniv>	what the user wants
15:48:26 <wbniv>	users
15:48:28 <SteffenPoulsen>	I think I might put some work into Personas .. would make all of this talk much easier to handle efficiently
15:48:45 <ArthurClemens>	great
15:48:53 <Lavr>	Performance was in Dakar's roadmap. But since noone took step 2 Dakar ended up being slower than Cairo.
15:49:08 <CDot>	Not true
15:49:09 <bitca>	And we can role play! We can each be a different persona!
15:49:13 <SvenDowideit>	humpf
15:49:16 <wbniv>	you weren't around for those discussions
15:49:18 <CDot>	step 2 was extensively discussed
15:49:19 <wbniv>	there were many
15:49:27 <SvenDowideit>	and many were implemented
15:49:36 <bitca>	So you discussed it and it *still* is slower?
15:49:38 <wbniv>	and MichaelSparks provided a lot of proof-of-concept work
15:49:40 <bitca>	Ummm.....
15:49:42 <CDot>	it was very clear, however, that TWiki has a fundamental problem
15:49:47 <SvenDowideit>	and then we had to devolve to be cairo compat
15:49:49 <Lavr>	Dakar is slower. That is a fact.
15:49:51 <CDot>	the architecture is constrained by the mission
15:50:04 <CDot>	compatibility requires it to be slow
15:50:09 <bitca>	Oh, bleh. Compatibility is the hobgoblin of tiny machines
15:50:19 <SvenDowideit>	when we de-cairo the code, we are quite fast
15:50:22 <CDot>	because performance-limiting decisions were taken too early in the design
15:50:49 <CDot>	if you allow me to break the compatibility rule, I will give you shit-hot-fast TWiki
15:50:50 <wbniv>	hehe, see complaint on #twiki right now :)
15:51:18 <bitca>	Just another one of your personae whinging, wbniv?
15:51:25 <Lavr>	Which is where I wanted to go. The TWikiMission is a beautiful text and I agree 99%. Except - we will never get anywhere with performance unless we let go of the "no upgrade script".
15:51:36 <wbniv>	oooh
15:51:38 <wbniv>	actually
15:51:52 <SvenDowideit>	yep
15:51:53 <ArthurClemens>	we've commented on the mission before
15:51:57 <wbniv>	the "no upgrade script" policy has other implications that are much worse than what you get with "no upgrade script"
15:51:59 <wbniv>	which is
15:52:04 <CDot>	there are compatibility constraints that no upgrade script can solve
15:52:04 <bitca>	Oh, I forgot a big mission-statement item: enable me to make money off of TWiki
15:52:06 <SteffenPoulsen>	bitca: If we actually did that, I believe we'd probably have an easier time finding our common ground than we're having at present
15:52:08 <ArthurClemens>	the upgrade script comment was slipped into it very late
15:52:21 <ArthurClemens>	and adhered to since then
15:52:41 <wbniv>	that the with the current design, twiki is supposed to upgrade topics as you go.  the problem is with all of the other scripts which then are required to know about all of the old format/decisions
15:52:46 <CDot>	bitca: remind me to have a chat with you about that
15:52:46 <Lavr>	The important requirement is protecting the investment in the information in the many topics.
15:52:54 <bitca>	money? Please do!
15:52:56 <wbniv>	because it's not just about editing the wiki with the text box
15:53:11 *	bitca provides many valuable services ;)
15:53:35 <wbniv>	and, there actually is one really simple upgrade script
15:53:43 <wbniv>	which is to load each topic and hit save
15:53:47 <wbniv>	if you want to look at it that way
15:54:17 <wbniv>	think about this: twiki upgrades old category tables to the new format
15:54:29 <wbniv>	but do *any* of the other tools deal with the old category stuff?
15:54:32 <wbniv>	i don't think so
15:54:37 <Lavr>	My users do not care if the topics are in text files or in a database. They care about not loosing all the work they have put into creating the information. This is where backwards compatibility has to be near 100%.
15:54:52 <bitca>	s/loosing/losing/ Please!!!
15:55:15 <CDot>	Lavr: and there's the rub. You can't have your cake *and* eat it
15:55:19 <ArthurClemens>	bitca: we will start in Danish and Dutch!
15:55:31 <ArthurClemens>	Ik dacht het niet!
15:55:34 <bitca>	pastries and chocolate?
15:55:50 <bitca>	or dikes?
15:56:03 <bitca>	(not that there's anything wrong with it)
15:56:04 <ArthurClemens>	Dus hou je mond over grammatica als je wil?
15:56:14 <ArthurClemens>	:-)
15:56:28 <SteffenPoulsen>	wbniv: Before this train leaves it tracks entirely, were you going to say something about Tinderbox?
15:56:30 <bitca>	Don't I add a pleasantly random element to our discussions?
15:56:48 <bitca>	Tinderbox is an excellent product written by a friend of mine
15:56:52 <SvenDowideit>	pleasant yes, random? i doubt it :)
15:56:58 <wbniv>	well, i've fixed the tinderbox and install scripts to be up to date
15:57:02 <wbniv>	and i'd like to deploy it
15:57:09 <wbniv>	but twiki.org can't (currently) handle the load
15:57:10 <SvenDowideit>	which refers to -2
15:57:14 <CDot>	bitca: you are the cosmic ray that lights up the tritium in our mile-deep detector. ;-)
15:57:15 <SvenDowideit>	more serverage
15:57:20 <wbniv>	and i can't run it on any of my hw
15:57:25 <bitca>	What the heck is Tinderbox?
15:57:27 <wbniv>	so, yes, either #2
15:57:31 <wbniv>	as sven points to
15:57:51 <SteffenPoulsen>	wbniv: how much "load" is in question?
15:58:07 <wbniv>	or, if i can find an appropriate box somewhere else to run it on, i can set it up there, and eventually switch it over to a tinderbox.twiki.org box when/if appropriate
15:58:09 <bitca>	(Tinderbox the product really is a wiki-like application. See Eastgate.com)
15:58:10 <SvenDowideit>	its not just to get it running on a machine
15:58:17 <SvenDowideit>	it will also load develop.twiki.org more
15:58:32 <wbniv>	about 1/2 hour as much cpu as possible after every checkin
15:58:36 <wbniv>	(or,
15:58:42 <SvenDowideit>	and develop.twiki.org is horribly loaded already
15:58:53 <SvenDowideit>	ideally, we need 3 machines
15:58:56 <SvenDowideit>	svn
15:59:00 <wbniv>	1/2 after every checkin after every completed tinderbox run 
15:59:02 <SvenDowideit>	develop test
15:59:04 <SvenDowideit>	tinderbox
15:59:05 *	bitca guesses no one is going to answer her
15:59:26 <SvenDowideit>	bitca, Tinderbox for us is an automated testing over-view system
15:59:37 <bitca>	Oh
15:59:42 <wbniv>	that is, a generic term, and nothing mozilla-related :)
15:59:50 <bitca>	There's testing?
16:00:05 <SteffenPoulsen>	why will it load develop.twiki.org?
16:00:21 <wbniv>	because develop.twiki.org is already over-loaded
16:00:34 <Lavr>	Testing is some little irritating Danish dog barking all the time :-)
16:00:42 <SteffenPoulsen>	oh, it was Svens comment, that it is "not just the machine"
16:00:48 <SvenDowideit>	because develop.twiki.org is the svn server
16:00:56 <wbniv>	and pth's personal  web hosting package, and not necessarily the appropriate place either
16:01:04 <SvenDowideit>	and svn uses resources like its going out of fashion
16:01:13 <SvenDowideit>	makes twiki look very fast and very small
16:01:18 <bitca>	That's because it's left out the 'e'
16:01:39 <SteffenPoulsen>	sync svn also, make tinderbox run off a local svn?
16:01:58 <SvenDowideit>	um
16:02:11 <CDot>	My parting shot: It is my belief that the current TWiki architecture - or rather, aspects of the architecture that have been exposed to twiki applications - fundamentally limit the potential for performance improvement in twiki. Caches etc will deliver some small gains, but huge performance gains are there for the taking if we can just let go of - or at least relax - our death-grip on the past. That means some compromise have to be made. 
16:02:11 <SvenDowideit>	the sync will load the primary server...
16:02:26 <SteffenPoulsen>	CDot: No long lines, you'
16:02:32 *	CDot (n=crawford@crawfordcurrie.plus.com) has left #twiki_edinburgh
16:02:36 <SteffenPoulsen>	re cut off after the "1" here
16:02:37 <bitca>	eek
16:02:52 <bitca>	That was some parting shot of his!
16:02:54 <SteffenPoulsen>	but sync after a commit is what we're all doing all the time?
16:03:13 <SvenDowideit>	SteffenPoulsen, yes, and thats too large a load already
16:03:25 <wbniv>	but the tinderbox would also need to perform a build
16:03:29 <SvenDowideit>	when you commit you are not syncing to a different co
16:03:30 <wbniv>	including all of the plugins!
16:03:39 <wbniv>	run the tests
16:03:42 <wbniv>	perform an installation
16:04:08 <SvenDowideit>	wbniv, you _need_ to look at PITA by AdamK
16:04:13 <wbniv>	tinderbox
16:04:13 <wbniv>	   * run the (unit) tests (tools$ perl build.pl)
16:04:13 <wbniv>	   * build a new twiki kernel (make kernel)
16:04:13 <wbniv>	   * build a new distribution (make distro)
16:04:13 <wbniv>	   * publish the distribution (make publish)
16:04:13 <wbniv>	   * install the distribution (TWikiInstallerContrib/bin/install-twiki.pl)
16:04:15 <wbniv>	      * (which is built on TWikiInstallerContrib's =twiki-install= web script)
16:04:17 <wbniv>	         * (which is built from =remote-install= combined with the code from TWikiExtensionInstallerContrib)
16:04:20 <wbniv>	      * SMELL: hmm, naming, user accounts, etc...
16:04:22 <wbniv>	   * run the (golden html) tests (dead atm)
16:04:24 <wbniv>	   * post the test results to tinderbox.wbniv.wikihosting.com
16:04:26 <wbniv>	      * SMELL: need to include link to the live installation!
16:04:27 <SvenDowideit>	i'd be very interested in using it
16:04:28 <wbniv>	SvenDowideit: what's that?
16:04:36 <wbniv>	i already have enough PITA's around here ;-)
16:04:41 <ArthurClemens>	nothing to add for me now
16:04:42 <SvenDowideit>	i'll send you info when i find it
16:04:43 <wbniv>	url?
16:04:45 <wbniv>	k, cool
16:04:54 <ArthurClemens>	bye people, bed time
16:04:59 *	ArthurClemens (n=ArthurCl@aclemens.xs4all.nl) has left #twiki_edinburgh ("Leaving")
16:05:01 <SteffenPoulsen>	ArthurClemens: cya around
16:05:02 <SvenDowideit>	sleep well :)
16:05:03 <bitca>	People are always leaving me
16:05:40 <Soronthar>	http://search.cpan.org/~adamk/PITA-0.20/lib/PITA.pm
16:05:58 <SvenDowideit>	Soronthar, thanks :)
16:06:16 <SteffenPoulsen>	SvenDowideit: I'm lost why exactly this load will to much for develop .. syncing a kilobyte or two once pr. hour? If it's done using rdiff-backup or similar it shouldn't present any trouble?
16:06:19 <Soronthar>	I'm not Soronthar, just a googling bot ;)
16:06:30 <bitca>	Beat me to it
16:06:44 <SvenDowideit>	SteffenPoulsen, because svn is a big nasty app
16:06:52 <bitca>	Too many hits
16:06:52 <SvenDowideit>	ON THE SERVER
16:06:59 <SteffenPoulsen>	running the berkeley backend?
16:07:00 <SvenDowideit>	ie dav_svn
16:07:02 <SvenDowideit>	no
16:07:03 <SvenDowideit>	fsfs
16:07:06 <wbniv>	SteffenPoulsen: it's more than sync'ing
16:07:15 <SvenDowideit>	bdb is crap
16:07:18 <wbniv>	producing a new build takes a good 10 minutes
16:07:20 <bitca>	COuldn't we get Motorola to give us lots and lots of money?
16:07:31 <SvenDowideit>	i've asked :)
16:07:35 <SvenDowideit>	but moto is poor
16:07:35 <AndreU>	CDot, what compromise do you see for taking TWikis architecture to another dimension?
16:07:40 <SteffenPoulsen>	wbniv: that's the part I am trying to understand, but I'm not getting there
16:07:43 <Lavr>	Hehe. 
16:07:51 <wbniv>	amd can't do anything unless there's some sort of legal entity to give things to
16:07:55 <SvenDowideit>	they can't even keep labs open without gov support
16:08:09 <SteffenPoulsen>	1) Snapshot the file system 2) sync a local repository 3) run tinderbox off the local copy
16:08:12 <bitca>	I know. I have a good friend who works there
16:08:31 <AndreU>	redesign of content structure?
16:08:49 <wbniv>	4) run the tests 5) perform a build 6) install the build 7) more tests on the installed version 8) post results
16:08:52 <Lavr>	Same problem as Mot. The amount is less of a problem than how to (red tape).
16:09:01 <bitca>	Reams of unindexed text is inherently inefficient, whether paper or bytes
16:09:05 <SteffenPoulsen>	but will 4-8 put load on develop.twiki.org as well?
16:09:11 <SvenDowideit>	no
16:09:11 <wbniv>	that's supposed to be 8 ) not a blood smiley face :)
16:09:21 <wbniv>	yes, 5 is a big one
16:09:29 <SvenDowideit>	but 1&2 are already more than we can deal with
16:09:36 <SteffenPoulsen>	wbniv: not if run on a seperate machine?
16:09:45 <SteffenPoulsen>	SvenDowideit: why?
16:10:06 <SvenDowideit>	run a large svn install - on a small flakey box, then you'll know
16:10:13 <wbniv>	SteffenPoulsen: right, running on a separate machine is what i'd like to do
16:10:20 <Soronthar>	AndreU: Remove all the "assuptions" the code have about the topic format and how META is store, for a start
16:10:23 <wbniv>	and the code supports running the various bits on different boxes
16:10:30 <wbniv>	it can be distributed quite a bit
16:10:44 <SteffenPoulsen>	SvenDowideit: But this has nothing to do with SVN, it's just syncing a file system that has changed a bit since the last sync, that's all?
16:10:52 <SvenDowideit>	no
16:10:56 <bitca>	Can't we just go to the NSA and ask for money nicely, claiming TWiki will fight terrorism?
16:11:04 <SvenDowideit>	it has to do with the hardware, and the config
16:11:11 <SvenDowideit>	both of which are trashed on that machine
16:11:24 <bitca>	Uh oh. I've probably just hit their all-encompassing sniffing and will be dragged off to a gulag shortly
16:11:30 <SvenDowideit>	and then svn which needs a bigger machine
16:11:37 <wbniv>	Soronthar: AndreU: being able to actually parse the topic?  not as a part of rendering?  
16:11:40 <AndreU>	Soronthar, ok I could imagine
16:11:51 <SvenDowideit>	fs level sncing requires rel security work, which can't happen on that machine either
16:12:05 <wbniv>	which means, making the parsing deterministic (and just working in general, dealing with quotes within quotes }% within }%, etc.)
16:12:13 <AndreU>	wbniv, that is a bit harder
16:12:29 <AndreU>	parsing special parts would be possible
16:12:31 <Soronthar>	wbniv: what you mean with "parsing the topic"?
16:12:32 <wbniv>	but is perhaps the biggest show stopper!  (i think so, anyway)
16:12:50 <Soronthar>	hmm.. slow typing, today
16:13:02 <SteffenPoulsen>	well, if you decide otherwise one day I'll be happy to lend some hardware to it
16:13:05 <wbniv>	to be able to store the parsed topic tree instead of constantly parsing and re-parsing the topic text all the time
16:13:41 <AndreU>	like it would be with an extended XHTML? :-)
16:13:56 <wbniv>	that's one way, but not a requirement
16:14:02 <bitca>	Yes! Let's store topics in XML!
16:14:08 <wbniv>	(even tho i've wanted for years for twiki to store topics in xml
16:14:19 <wbniv>	notice i said *store* --- not how it's presented to the user
16:14:25 *	bitca blinks
16:14:40 <AndreU>	XHTML would be easier for the whiteboard, as there are tools ready
16:15:01 <wbniv>	y, that's part of the appeal --- to fit in with the large collection of xml-processing tools
16:15:17 <AndreU>	but CDot, mentioned some architectural decisions
16:15:19 <Soronthar>	bitca: NOOOO, XML NOOO!!!
16:15:22 <AndreU>	to make twiki faster
16:15:35 <Lavr>	Let us store topics in morse code -...  ..  _  _._.  -_ 
16:15:45 <bitca>	or how about....bits!
16:15:52 <Soronthar>	I really prefer morse to XML
16:16:04 <bitca>	It must be silly season somewhere
16:16:05 <wbniv>	well, just make it pluggable, and you can have either! ;-)
16:16:05 <Lavr>	Last one should have been ._
16:16:09 <AndreU>	bring TWiki on a framework like http://catalyst.perl.org/ ?
16:17:09 <bitca>	Jeez. You know morse code?!
16:17:42 <wbniv>	anyway, whether it's stored in xml or some other format is *completely* besides the point; don't get distracted by that implementation bit
16:17:48 <Lavr>	-.-- . ...
16:17:50 <wbniv>	the important thing is to make it pre-parsable
16:17:57 <wbniv>	(imho)
16:18:09 <Soronthar>	wbniv: agree
16:18:37 <wbniv>	and finer granularity, with dependencies
16:18:56 <wbniv>	parts of building an effetive cache system
16:19:02 <Soronthar>	i have to say it again: Pluggable Implementations.
16:19:23 <AndreU>	I would like to hear what Crawford had in mind by making a compromise about the architecture
16:19:32 <Soronthar>	that's the fundation to be backward compatible plus be able to spring forward
16:19:53 <wbniv>	Soronthar: right - relates to the small kernel design cdot referred to earlier
16:20:09 <Soronthar>	I think he wrote about those in Codev these last days.
16:20:15 <wbniv>	if it's really an engine, you could argue that at the core it doesn't matter how it's stored
16:20:48 <wbniv>	it's just a store, query, and render thingee
16:20:51 <bitca>	It's important to know what the Perl compiler is not. It's not something which will magically make your code go faster, or take up less space, or be more reliable. The backends which generate standalone code generally do exactly the opposite. 
16:21:38 <wbniv>	bitca: although that's true, how does that relate to what we're talking about?
16:21:48 <wbniv>	this isn't anything related to perl
16:21:54 <wbniv>	it's data abstraction and representation
16:22:02 <bitca>	Sorry. wrong window
16:22:06 <wbniv>	hehe :)
16:22:18 <bitca>	Although it does have something to do with performance
16:22:37 <Lavr>	With respect to performance. We can optimize code from now till doomsday. The perl code typically takes 0.4 seconds to process a topic. Getting it down to 0.2 seconds it not the real issue. The real issue is that TWiki has to read 20000 topics in a search used in a topic for example.
16:22:54 <bitca>	True.
16:23:03 <Soronthar>	the answer to that is plucene
16:23:23 <bitca>	whoa. a word i'm not familiar with. sounds intellectual.
16:23:26 <Soronthar>	very good indexing by keyword.
16:23:28 <wbniv>	no, that only addresses part of it
16:23:47 <Lavr>	When you search in a MySQL database it takes a fraction of the time to search the same amount of data.
16:23:59 <wbniv>	unless you've got fine granularity and proper dependencies, you'll have to do too much work every save
16:24:02 <Soronthar>	Plucene don't care how the topic is stored, as it's never readed to perform the search
16:24:05 <wbniv>	and especially painful for large wikis
16:24:25 <wbniv>	GINORMOUS wikis
16:24:29 <Lavr>	Think of Google. Imagine that made in TWiki and search for sex. The earth would no longer exist when it returned the hits.
16:24:33 <bitca>	How much time is spent editing and saving versus reading?
16:24:34 <Soronthar>	bitca: +  Author: Luisa Ledezma
16:24:38 <Soronthar>	oops
16:24:43 <Soronthar>	bitca:http://search.cpan.org/dist/Plucene/
16:24:43 <bitca>	Good one, Lavr
16:24:46 <SteffenPoulsen>	Lavr: how do you match MySQL content with a regexp?
16:25:20 <SteffenPoulsen>	loading the whole thing to RAM I s'pose .. not especially fast, last time I tried ..
16:25:21 <Lavr>	I am not saying MySQL is the solution. Just giving an example.
16:26:26 <bitca>	http://dev.mysql.com/doc/refman/5.0/en/regexp.html
16:27:24 <Lavr>	I wonder how fast that is compared to normal simpler searches.
16:27:40 <SteffenPoulsen>	bitca: interesting .. works on topic size cells (not just varchar)?
16:28:32 <bitca>	Dunno...looking...
16:29:34 <bitca>	MySQL provides standard SQL pattern matching as well as a form of pattern matching based on extended regular expressions similar to those used by Unix utilities such as vi, grep, and sed.
16:30:11 <SteffenPoulsen>	I'm curious what will happen if its fed a BLOB or similar
16:30:23 <Lavr>	The difficult place to be backwards compatible is TWiki apps that searches meta data. That is going to be a challenge to ever make backwards compatible.
16:31:51 <Soronthar>	To be able to support TWikiApps that search META using SEARCH (pre-dakar apps for sure) the meta *must* be embeded in the text
16:32:16 <bitca>	Doesn't say that it's limited to varchars. Or haven't found it, anyway
16:33:02 <wbniv>	Soronthar: no, but SEARCH could look in 2 places
16:33:05 <SteffenPoulsen>	interesting twist - never thought they'd begun supporting that .. performance with regexps might actually be possible, then .. 
16:33:05 <Lavr>	But then - you could have a compatibility mode where metadata are also in the "text". Or emulated to be present in text.
16:33:14 <bitca>	An example from the comments: SELECT * FROM site WHERE html REGEXP "id=[[.apostrophe.][.quotation-mark.]]archives[[.apostrophe.][.quotation-mark.]]";
16:33:21 *	SvenDowideit has quit (Read error: 110 (Connection timed out))
16:33:58 *	SvenDowideit (n=sven@203-217-85-207.dyn.iinet.net.au) has joined #twiki_edinburgh
16:34:01 <Lavr>	THere are wikis that run with data in databases. How do they scale? There must be some numbers.
16:34:11 <Soronthar>	Lavr: Yep, and could be a performance killer.
16:34:17 <SteffenPoulsen>	wikipedia seems to scale OK :-)
16:34:18 <bitca>	wikipedia is humongous
16:35:21 <Soronthar>	I think that, at the end, the most that we can provide is compatibility and a roadmap for migration.
16:35:50 <Soronthar>	so you can use the compatibility module while migrating the app to use the latest bells and whistles
16:36:37 <bitca>	Compatibility mode could hardly be slower than the status quo. Since it *is* the status quo.
16:36:53 <Lavr>	Yes. and make new syntax for new search. And leave the old SEARCH slow and backwards compatible. That is the way we have to think.
16:37:27 <Soronthar>	sound good
16:38:06 <bitca>	http://meta.wikimedia.org/wiki/MediaWiki_architecture
16:38:38 <bitca>	As of February 2005, the "cur" table of the English Wikipedia holds 3 GB data and 500 MB index (download as 500 MB compressed dump) while the "old" table holds 80 GB data and 3 GB index (download as 29 GB compressed dump).
16:41:23 <Lavr>	I am looking at phpwiki. I believe it is MySQL based. The demo site they run at Sourceforge is dead slow.
16:41:39 <bitca>	Note, it's at Sourceforge
16:41:52 <bitca>	The English Wikipedia has reached 900,000 articles.
16:42:10 <Lavr>	Yes. I know their servers are awfully loaded.
16:42:33 <bitca>	There are numerous branches and forks of phpwiki
16:42:59 <wbniv>	i'd also like to point out there are lots of places where TWikiApplications have to use regular expression searches not because they "should", but because there isn't a proper interface to the structured data.  often, we use regular expressions to match a field and its value, but if we could get to it more directly....
16:44:51 <bitca>	It would be interesting to search for searches
16:45:11 <Lavr>	Yes. Structured data so you mix wiki and simple database type features is nice.  But if you have 2000 topics that uses the old regex searches you would not want to loose all those by upgrading to Edinburg. This is where we need the backwards compatibility - even if it is as slow as it used to be.
16:45:59 <bitca>	The MediaWiki software is written in PHP and uses the MySQL database.
16:46:52 <Lavr>	Those Twiki apps where searches are used on a few central topics and searching for simple topics - maybe with forms - are not too difficult to get upgraded in a 1-2 months period so you eventually take advantage of the new faster features.
16:47:39 <bitca>	Not to mention that existing customers will abandon TWiki if it starts running too slowly
16:48:10 <bitca>	How much of the performance hit is due to plugins?
16:48:43 *	SvenDowideit_ (n=sven@203-166-246-247.dyn.iinet.net.au) has joined #twiki_edinburgh
16:49:00 <bitca>	The more technical folks should peruse a lot of this: http://meta.wikimedia.org/wiki/Database_layout
16:50:01 <Soronthar>	bitca: it depends on the plugin. CDot did a lot of work to reduce the plugins overhead.
16:51:38 <bitca>	I ask only because that seems to be a major difference between mediawiki and twiki
16:53:10 <Lavr>	Just take a live example. Exactly the same topic. But with different number of topics to search.
16:53:18 <Lavr>	http://www.lavrsen.dk/twiki/bin/view/Open2300/BugReports
16:53:35 <Lavr>	http://www.lavrsen.dk/twiki/bin/view/Motion/BugReports
16:55:15 <Lavr>	There are round 740 topics to search in in the Motion web. And 115 in the Open2300 web.
16:55:25 <Soronthar>	Motion is Cairo based?
16:55:41 <Lavr>	Both are LOW numbers of topics compared to what you have in a corporate TWiki.
16:55:54 <Lavr>	No Soronthar. It is the same Twiki. Same Dakar.
16:56:08 <Soronthar>	sorry, didn't read the url
16:56:19 <Soronthar>	hmm..
16:56:25 <Lavr>	But you can clearly feel the difference in response time between the two.
16:56:37 <bitca>	yes
16:56:43 <Lavr>	Even here with a 100Mbit link to my server.
16:56:47 <SvenDowideit_>	bitca, thats wrong
16:56:52 <Lavr>	Imagine a web with 70000 topics.
16:57:01 <SvenDowideit_>	the fundamental difference between twiki and mediawiki
16:57:02 *	AndreU has quit (Connection timed out)
16:57:11 <SvenDowideit_>	is that twiki is very dynamic
16:57:24 <SvenDowideit_>	whereas mediawiki in comparison is almost static
16:57:43 <bitca>	What makes twiki dynamic?
16:57:50 <SvenDowideit_>	if all we had to do was add <b> and <a href
16:57:57 <SvenDowideit_>	then its would be dead easy
16:58:12 <bitca>	I mean, what do you mean by "dynamic"
16:58:29 <Lavr>	Just look up TWikiVariables and note how many live features we have. MediaWiki has close to none.
16:58:30 <SvenDowideit_>	twiki has multiple layers of variables, each if which can result in more topic being rolled into a topic output
16:58:54 <bitca>	I guess I was conflating plugins and twiki variables
16:59:16 <Lavr>	On top of that you have the plugins.
16:59:19 <SvenDowideit_>	thats why i keep telling people that the major reason they have performance problems is because they did not spec an appropriate server
16:59:31 <SvenDowideit_>	(not that its not horribly slow)
16:59:43 <bitca>	What is the difference between plugins and variables?
16:59:52 <SvenDowideit_>	if you want all the bells and whistles, you have to pay for it in the end
16:59:55 <Lavr>	But the real performance issue in TWiki is searching for anything. Not that it takes 400 ms to compile the perl code.
16:59:56 <SvenDowideit_>	complexity
17:00:05 <SvenDowideit_>	Lavr, yep
17:00:17 <SvenDowideit_>	and so long as people insist on keeping the brain dead SEARCH
17:00:21 <SvenDowideit_>	thats how it will be
17:00:33 *	PeterThoeny_ has quit (Read error: 113 (No route to host))
17:00:39 <bitca>	I second braindead
17:00:45 <SvenDowideit_>	bitca, how often is getRenederedVersion or whatever called in a plugin?
17:01:01 <SvenDowideit_>	thats because of the multiple layers of re-rendering
17:01:21 <SvenDowideit_>	admittedly due to poor design, but again - thats a compatibility slowdown
17:01:33 <SvenDowideit_>	it easy to talk about focussing on performance
17:01:52 <Lavr>	Well. We probably need to keep current SEARCH for backwards compatibility. We need some NEW search features combined with some sort of indexed topic storage.
17:02:10 <SvenDowideit_>	on which the old search will not work
17:02:17 <Lavr>	Never mind the old SEARCH remains slow.
17:02:27 <SvenDowideit_>	at least - you are probably kidding yourself if you thing people will manage to maintina it
17:02:46 <SvenDowideit_>	remember, its not just a design, impl, add more code issue
17:02:54 <SvenDowideit_>	you also have to look at the resourcing issue
17:03:10 *	SvenDowideit has quit (Read error: 110 (Connection timed out))
17:03:37 <Lavr>	Why should you not be able to do "braindead" search in an indexed data storage?
17:03:59 <SvenDowideit_>	personally i think keeping more than one code path is unlikely to be successful, because the few developers will probably focus on making just one owrk
17:04:22 <SvenDowideit_>	and the other will become crufty, and thus not sufficiently functional
17:04:31 <bitca>	Cannot old searches be translated?
17:04:43 <SvenDowideit_>	should is a very different thing form realistically
17:04:43 <bitca>	And how did the last meeting roll over into this one?
17:04:57 <SvenDowideit_>	cos i missed most of this one :(
17:05:09 <SvenDowideit_>	and i'm outta here - back in 2-3 hours
17:05:16 <Lavr>	If you loose backwards compatibility you may as well start a new Wiki project and abbandon TWiki. You have something like 2000-3000 TWiki installations out there with millions of topics.
17:05:31 <SvenDowideit_>	Lavr, thats why i argue for upgrade script
17:05:39 <SvenDowideit_>	then we have both
17:05:54 <Lavr>	I agree with upgrade script. I cannot see any issue with that
17:05:59 <bitca>	backward compatibility can include automated migration
17:06:11 <SvenDowideit_>	mind you, abandoning twiki is always a useful thing - i wanted to make it a medaiwiki killer, but can't under the current rules
17:06:20 <SvenDowideit_>	bitca, not at present it can't
17:06:42 <bitca>	For example, an argument was made previously that many searches are key-value searches
17:06:43 <Lavr>	But you would have to be very inventive to write a script that can convert all braindead searches into intelligent searches.
17:06:47 <bitca>	(or something close to that)
17:06:49 <SvenDowideit_>	i started the upgrade script - and due to the way twiki is delived, fuck its hard
17:07:04 <SvenDowideit_>	Lavr, yep
17:07:27 <bitca>	Perhaps a survey of searches used at a variety of important (by some definition) sites should be done?
17:07:41 <SvenDowideit_>	anyway -see oyu guys :)
17:07:55 <Lavr>	See you Sven.
17:08:14 <bitca>	One also has to wonder how many of the existing sites are dead and/or don't plan to upgrade
17:08:51 <Lavr>	Remember - most webpages - also the static are old junk.
17:09:16 <Lavr>	Example: http://chayer.dk/
17:09:33 <bitca>	rofl
17:10:03 <bitca>	Oh. I was about to ask you how you chose that page, then i noticed... The Bitca herself!
17:10:23 <bitca>	Oh, god. You met at a Cline Dion concert? *cringe*
17:10:31 <Lavr>	Yep.
17:10:51 <Lavr>	We are going to Las Vegas to see her in April.
17:11:15 <bitca>	I've seen Springsteen over 55 times
17:11:57 <Lavr>	I have only seen him twice. But both were great concerts ;-)
17:12:39 <bitca>	OK. You're OK in my book then
17:13:09 <bitca>	I'm very late watching the news now
17:13:30 <Lavr>	Denmark still on the news?
17:13:46 <bitca>	Forever, I imagine. sigh.
17:14:56 *	Soronthar has quit (Read error: 110 (Connection timed out))
17:15:31 <Lavr>	Well. I will also go to sleep. It is 1:15 AM here. Nice talking to you all. 'night
17:16:50 <bitca>	nite nite