**** BEGIN LOGGING AT Mon Feb 6 13:57:07 2006 Feb 06 13:57:07 * Now talking on #twiki_edinburgh Feb 06 13:57:07 * Topic for #twiki_edinburgh is: http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x02x06 Feb 06 13:57:08 * Topic for #twiki_edinburgh set by SamHasler at Mon Feb 6 13:56:05 2006 Feb 06 13:57:26 hi andre: it starts in a few minutes Feb 06 13:57:43 ok Feb 06 13:58:14 Hey everyone Feb 06 13:58:24 SamHasler - great to see you here! Feb 06 13:58:35 hi Lynnwood Feb 06 13:59:25 Hey AndreU - good to see you also! Feb 06 13:59:28 hi andre, kenneth, lynnwood and sam! Feb 06 13:59:58 * SteffenPoulsen (n=step@cpe.atm2-0-1151196.0x503f90c2.arcnxx11.customer.tele.dk) has joined #twiki_edinburgh Feb 06 14:00:00 * ArthurClemens (n=arthurcl@aclemens.xs4all.nl) has joined #twiki_edinburgh Feb 06 14:00:03 * MartinCleaver (n=chatzill@CPE00c049bf409e-CM014380021963.cpe.net.cable.rogers.com) has joined #twiki_edinburgh Feb 06 14:00:11 * MartinCleaver (n=chatzill@CPE00c049bf409e-CM014380021963.cpe.net.cable.rogers.com) has left #twiki_edinburgh Feb 06 14:00:55 hi all :-) Feb 06 14:01:06 hi steffen! Feb 06 14:01:23 brb Feb 06 14:01:24 anybody heared of sven? is he joining? Feb 06 14:01:27 heya Feb 06 14:01:27 * SamHasler has quit ("Chatzilla 0.9.69.3 [Firefox 1.5/2005111116]") Feb 06 14:01:33 hi arthur! Feb 06 14:01:37 sven? Feb 06 14:01:55 please don't wake me :) Feb 06 14:02:05 oh, hi sven! Feb 06 14:02:10 is it early? Feb 06 14:02:13 moinmoin Feb 06 14:02:18 na, just a bad night Feb 06 14:02:19 glad to see there's some interest still, less pressure on things tonight Feb 06 14:02:22 * SamHasler (n=SamHasle@twiki/developer/SamHasler) has joined #twiki_edinburgh Feb 06 14:02:23 very windy Feb 06 14:02:36 like that Feb 06 14:03:04 what's "windy" in australian terms .. roofs blowing off? :-) Feb 06 14:03:17 yep Feb 06 14:03:22 alligators flying by? Feb 06 14:03:39 :-) Feb 06 14:03:42 Looking over the agenda, I'd like to add one item: offering patched files for fixes. Feb 06 14:03:47 ok, it wasn't that windy, but yes, that happens at least once a year Feb 06 14:04:17 Today I downloaded WebKit. They have a nice testers homepage! Contrasting to Bugs' yellow warning... Feb 06 14:04:17 Are we about ready to begin? Feb 06 14:04:21 http://nightly.webkit.org/start/ Feb 06 14:04:24 i think so Feb 06 14:04:24 I'd like to ammend that to we offer 3 packages Feb 06 14:04:32 who is taking the minutes? Feb 06 14:04:44 lynnwood is facilitating Feb 06 14:04:46 * SteffenPoulsen volounteers again! Feb 06 14:04:56 cool, thanks steffen! Feb 06 14:05:00 Yay Steffen! Feb 06 14:05:18 - as long as you do the talking :-) Feb 06 14:05:41 SvenDowideit_ - did you mean to ammend my proposed agenda item? Feb 06 14:05:47 yep ;) Feb 06 14:05:58 i think we have critical mass to start Feb 06 14:06:02 OK. Feb 06 14:06:30 perhaps we can discuss that under the discussion re 4.0.1 release Feb 06 14:06:52 Do we have a timeframe for today's meeting? Feb 06 14:07:07 goal is 90 minutes as usual Feb 06 14:07:10 How about trying to keep it under 90 minutes? Feb 06 14:07:11 OK Feb 06 14:07:36 yap, first item: review of http://twiki.org/cgi-bin/view/Codev/DakarReleaseMeeting2006x01x30 Feb 06 14:07:39 Regarding review of DakarReleaseMeeting2006x01x30 Feb 06 14:07:54 Peter - can you touch upon items there we need to review? Feb 06 14:08:06 let me see... Feb 06 14:08:16 also, all: please bring forward what needs attention Feb 06 14:08:33 Presumably - most of this is old news - i.e. pre-release stuff. Feb 06 14:08:52 http://twiki.org/cgi-bin/view/Codev/HandlingCairoDakarPluginDifferences needs some more doc work Feb 06 14:09:00 I think we got most of it covered, plugins are still an item though Feb 06 14:09:04 it is already linked from the supplemental docs Feb 06 14:09:30 i have nothing else on the last minutes Feb 06 14:10:11 OK - shall we just add discussion of plugins to today's agenda? Feb 06 14:10:12 ok, moving on .. next item might have more voices Feb 06 14:10:30 Nothing changed on the COVER documentation Feb 06 14:10:49 ArthurClemens: nope, waiting for CDot I s'pose Feb 06 14:11:05 For CDot the question is not clear I suppose Feb 06 14:11:10 for him its obvious Feb 06 14:11:14 it will be Feb 06 14:11:20 http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1534#r6 Feb 06 14:11:26 once he's back we'll discuss it Feb 06 14:11:36 ok Feb 06 14:11:41 i've found that if i want to use wysiwyg for eg Feb 06 14:11:47 so just note this as a followup item from last meeting. Feb 06 14:11:49 that cover is basically useless Feb 06 14:12:03 as changing it breaks wysiwyg Feb 06 14:12:54 I think the occational user will care little for Cover. It is worth letting CDot doc it when he is back. Feb 06 14:13:03 yep Feb 06 14:13:09 I have nothing else from that meeting Feb 06 14:13:10 noone here knows anything .. will you add it to the bug item, Sven? Feb 06 14:13:25 (I will note a action item for you, then) Feb 06 14:13:29 y Feb 06 14:13:30 ready to move to TWiki 4.0.1 release? Feb 06 14:13:32 thanks Feb 06 14:13:37 :) Feb 06 14:13:52 we have two major fixes Feb 06 14:14:00 file:///D:/Documents%20and%20Settings/Sam%20Hasler/My%20Documents/My%20Projects/FireFox/Chatzilla/motifs/output-mullusko-light.css Feb 06 14:14:01 the speed issue and the parent loss issue Feb 06 14:14:22 hey warrant a dot release Feb 06 14:14:28 ops :") Feb 06 14:14:29 s/hey/they/ Feb 06 14:14:38 Those are the easy parts. They are fixed. There are still some open issues. Feb 06 14:14:51 ok, please describe Feb 06 14:14:55 y, what about the other commits that have been done since 4.0.0 Feb 06 14:15:05 Item 1586 needs attention. Feb 06 14:15:10 BlacklistPlugin Feb 06 14:15:30 isn't that something taht can be solved in the plugin? Feb 06 14:15:38 or does that need a core change? Feb 06 14:16:05 Not sure. But BlacklistPlugin is pretty vital for public sites. Feb 06 14:16:36 in cairo, the register script was just used for registration Feb 06 14:16:53 in dakar it looks like it is also used for reg. confirmation Feb 06 14:17:11 that means, the blacklistplugin needs to be made aware of that Feb 06 14:17:23 e.g. no action if registration confirmation Feb 06 14:18:11 Yes. I think the solution is not difficult. The plugin need to only use magic number in the initial register. Not when you verify your registration. Feb 06 14:18:34 exactly Feb 06 14:18:40 just checked doc, http://twiki.org/~pthoeny/bin/view/TWiki/TWikiScripts#register Feb 06 14:18:54 there is an action: register or verify or resetPassword or approve Feb 06 14:19:03 so it should be easy to fix in the plugin Feb 06 14:19:04 I would also propose that the secret field is added to the registration form. It does not harm and I as an experienced user forgot about adding the field when installing the plugin. Feb 06 14:19:20 good point kenneth Feb 06 14:19:47 action item for whom? Feb 06 14:19:49 sounds reasonable .. Feb 06 14:20:17 Agreed to add this change for 4.0.1? Feb 06 14:20:28 yes Feb 06 14:20:33 as an action item? OK Feb 06 14:20:39 well, I know nothing about BlackListPlugin .. but I guess I could dive in and see what it's about Feb 06 14:21:00 it means though that if the plugin is not installed there will be an unresolved variable in the hidden field (which does not harm) Feb 06 14:21:00 who is main maintainer? Feb 06 14:21:07 me Feb 06 14:21:10 ah :-) Feb 06 14:21:15 well, I'll give it a shot then Feb 06 14:21:19 To clarify: is the action item simply to add the secret field to the registration form? Feb 06 14:21:35 for 4.0.1 release, yes Feb 06 14:21:42 but plugin needs to be fixed asap too Feb 06 14:21:57 but that's a separate task. Yes? Feb 06 14:22:02 that one is an action item for me Feb 06 14:22:03 and not as pressing? Feb 06 14:22:13 separate tasks Feb 06 14:22:18 what about the other commits that have been done since 4.0.0? Feb 06 14:22:25 Adding the field is simple. It is the plugin fix that needs a perl guru. Feb 06 14:22:30 Like Steffen ;-) Feb 06 14:22:58 flattering always did wonders :-) Feb 06 14:23:00 Thoughts on Sven's question? Feb 06 14:23:07 other commits: i do not see any compatibility/stability issues besides the last commit on removing undocumented fucntionality Feb 06 14:23:19 I have been following each commit and I implemented all and tested it. It all looks good. Feb 06 14:23:20 Sven, is your question if these should be in Dakar or Edin? Feb 06 14:23:49 I want to know if i need to branch, and selectivly merge in one a few commits to make 4.0.1 Feb 06 14:23:50 yes - that's the key question. Feb 06 14:23:56 that one's on me .. depricated this style: [[WikiName#Anchor link text]] .. did anyone use that? Feb 06 14:24:03 None of the commits are new features. They are all bug fixes. Feb 06 14:24:06 or if everything in DEVELOP should go into 4.0.1 Feb 06 14:24:41 Ah.Steffen I think THAT change is dangerous. It was documented and probably used. Feb 06 14:24:46 As a general strategy - it seems we need the branch since we can presume that not every new thing added should be included in 4.0.x releases. Feb 06 14:24:51 on removing functionality, this should be edinburgh only, following the http://twiki.org/cgi-bin/view/Codev/ProcessToDocUndocumentedStuff Feb 06 14:24:51 I did a tiny change to more.pattern.tmpl, including adding an English text Feb 06 14:24:59 Lavr: OK, I'll add it back in as a special case Feb 06 14:25:21 SteffenPoulsen, no Feb 06 14:25:29 no-one remove anything Feb 06 14:25:34 I personally never used it or say anyone using it - but I remember having seen it so I am sure someone somewhere used it. Feb 06 14:25:55 guys, we have a documented process Feb 06 14:26:05 no we don't Feb 06 14:26:22 sven: follow the link i posted Feb 06 14:26:24 not one that has ever been used for a 0.01 release Feb 06 14:26:41 oh, you changed the subject :( Feb 06 14:26:49 Peter - what link? Feb 06 14:26:56 http://twiki.org/cgi-bin/view/Codev/ProcessToDocUndocumentedStuff Feb 06 14:27:00 thanks Feb 06 14:27:20 Ehm, I added a MAKETEXT. So either I make it plain English, or the language tool should be run once. Feb 06 14:27:20 i'm trying to work out what i need to do for the 4.0.1 release Feb 06 14:27:38 and it sounds like i'm going to have to branch Feb 06 14:27:45 and then nerge across only certain changes Feb 06 14:27:54 [[Web.odd wiki word#anchor][display text]] etc is documented in the code, thus should follow the deprecation process Feb 06 14:28:02 * SamHasler is now known as SamHasler|Away Feb 06 14:28:10 Sven - I can't see any other option and still be able to selectively include changes in maintenance releases. Feb 06 14:28:30 y, thats why i asked if there were any things that were not selectred :) Feb 06 14:28:33 PeterThoeny: That one is intact, untouched, searched all docs for the other one, didn't find anything mentioning it Feb 06 14:28:37 and as there are, its branching time Feb 06 14:28:42 that is agenda item 4. Split DEVELOP branch Feb 06 14:28:55 no, thats still 4.0.1 item Feb 06 14:29:04 OK but it relates to 4.0.1 discussion. Feb 06 14:29:04 as without that info i can't do it Feb 06 14:29:05 but I should have just added it to the undoc topic, and marked it for later removal, agreed Feb 06 14:29:28 Steffen. The syntax you removed it in the standard syntax help topic in Cairo. Feb 06 14:29:29 This is somewhat of an aside on this issue.. Feb 06 14:29:29 If we offered the pre-patched files for downloading, the pressure to offer complete revised complete packages would be less. Adding a couple of changed files is a lot easier that downloading and applying each of the patches. Feb 06 14:29:49 TextFormattingRules in Cairo. Feb 06 14:29:54 1 want to ofer 3 things Feb 06 14:30:37 a real patch, a set of updated files to copy over an existing install Feb 06 14:30:37 and a full package Feb 06 14:30:39 the first 2 are derived from the last Feb 06 14:30:58 But do we have the infrastructure/time to do this now? Feb 06 14:31:04 yes Feb 06 14:31:13 i use build.pl to make the full tgz Feb 06 14:31:20 and then manually can make the other 2 Feb 06 14:31:37 which is a pretty simple jobbie Feb 06 14:31:40 OK. Feb 06 14:31:44 sounds good Feb 06 14:31:45 a wee joobbie Feb 06 14:31:53 Lavr: [[WikiWord#NotThere]] comes close, but that's not it .. it's when you start clickable text just by entering a space after the anchor Feb 06 14:32:03 I would just add that it would be great to offer the pre-patched file at same time as the patches. Feb 06 14:32:04 branching and building from the branch is many magnitudes larger Feb 06 14:32:13 see Feb 06 14:32:17 Steffen: [[http://xml.org XML]] Feb 06 14:32:17 a real patch, a set of updated files to copy over an existing install Feb 06 14:32:27 a real patch, _AND_ a set of updated files to copy over an existing install Feb 06 14:32:54 Lavr: argh, was looking for the achor *sigh* .. you sure know how to argue, action item for me :-) Feb 06 14:33:33 for 4.0.1 we should not introduce spec changes Feb 06 14:33:55 so 8706 should be reverted or cleaned up Feb 06 14:33:56 So could the patch + file be interim measure prior to 4.0.1? Feb 06 14:33:58 peter, can you stop talking about spec? Feb 06 14:34:27 Peter's point is good in terms of what to include in maintenance releases. Feb 06 14:34:28 as i'm never sure if you mean the docco we wrote before dev (that does not exist), the code, or the existing docco Feb 06 14:34:51 spec == specification == something twiki does not have Feb 06 14:35:12 Lynnwood, that would be a manual thing Feb 06 14:35:17 and not a managed release Feb 06 14:35:23 which we want to avoid Feb 06 14:35:42 sven, i know we see things differently, for me undocumented code is spec (until documented and changed) Feb 06 14:35:59 I understand. But I don't want it to wait for implementing more infrastructure for managed releases. Feb 06 14:36:19 This particular case was not undocumented. It was VERY documented. Feb 06 14:36:19 manual is fine for interim. I'll volunteer to add patch and upload file. Feb 06 14:36:22 Lynnwood, tough? Feb 06 14:36:45 if we don't do it propoerly, then 4.0.2 will have a good chance of not being the same as 4.0.1 Feb 06 14:36:47 and so on Feb 06 14:37:05 we've worked hard on making repeatable builds Feb 06 14:37:15 we do not want to loose that now Feb 06 14:37:16 Lavr: any change you will stop running my nose in it any time soon? *g* Feb 06 14:37:39 That was not meant for you Steffen. Feb 06 14:38:00 * SteffenPoulsen lightens up Feb 06 14:38:05 Twiki has a lot of docs. Noone is expected to remember them all by heart. Feb 06 14:38:08 I agree - but I don't want to rush the process for automating the build and patch release - and I think it's important to offer the patched files immediately. Feb 06 14:38:37 partially to take off pressure for 4.0.1 while you finish work on automating the process Feb 06 14:38:57 i see a consensus here: release asap with bug fixes and without introducing different behaviour Feb 06 14:39:13 i strongly suggest that you cannot tell what is going to be in 4.0.1 until the automation is done Feb 06 14:39:44 what automation? Feb 06 14:39:54 I agree with peter, people don't expect new ways of doing things now, let's release asap Feb 06 14:39:59 the build, from a branch Feb 06 14:40:12 plus the patch and pre-patched files. Feb 06 14:40:14 i was going to release 4.0.1 tonite Feb 06 14:40:22 sven: we have not yet branched, so we are still on DEVELOP Feb 06 14:40:24 from a branch Feb 06 14:40:42 so in the interest of time, release 4.0.1 first, then branch Feb 06 14:40:46 4.0.1 will obviously not be Feb 06 14:40:46 no Feb 06 14:41:03 * PeterThoeny is listening Feb 06 14:41:07 you guys have just made it clear that DEVELOP contains stuff that is not for 4.0.1 Feb 06 14:41:28 before i can build i also need to commit the 4.0.0 release into a tag Feb 06 14:41:32 oh, it will if 8706 is reverted Feb 06 14:41:34 and pull form there Feb 06 14:41:37 no Feb 06 14:41:42 there have been more commits Feb 06 14:41:52 Sven. DEVELOP is fine for 4.0.1. Except for a small fix that Steffen will have done before you have time to check ;-) Feb 06 14:41:57 As general principle, do we agree that 4.0.1-9 release would not add or change functionality? i.e. just provide fixes. Feb 06 14:42:02 and the one ArthurClemens made Feb 06 14:42:04 i think those are bug fixes and very minor enhancements Feb 06 14:42:09 and any others we might have forgotten Feb 06 14:42:21 But maketext tool should be run Feb 06 14:42:32 not for 4.0.1 Feb 06 14:42:35 seems like even nior enhancements should wait for 4.x releases Feb 06 14:42:40 y Feb 06 14:42:45 s/nior/minor Feb 06 14:42:57 well, in our (and in particular my) best judgement we only made _improvements_ .. real bugfixes for real errors Feb 06 14:42:59 i was fully expecting that today i would Feb 06 14:43:05 1 commit 4.0.0 tag Feb 06 14:43:23 2 branch 4.0 Feb 06 14:43:45 3 move across _only_ the commits listed on the fixes topic Feb 06 14:43:52 4 build and upload Feb 06 14:44:02 5 make patch and updated files Feb 06 14:44:20 at the moment, there are only 2 commits to merge across Feb 06 14:44:38 if there are more fixes, they need to be listed on the release topic Feb 06 14:44:50 2? There are more fixes than two. Feb 06 14:44:59 sven: why not take all minor fixes? Feb 06 14:45:02 OK, I will list them, no problem - there are ~10 that needs to go in Feb 06 14:45:05 doing it this way means we know exactly what is in the release Feb 06 14:45:14 list all of them on the release topic Feb 06 14:45:19 and i will merge them across Feb 06 14:45:47 Any objections to Sven's proposal as amended by Steffen? Feb 06 14:45:48 PeterThoeny, its not that i don't want them, we don't know what they are at this point Feb 06 14:46:00 sven: in the interest of time, i suggest to release 4.0.1 first, then branch Feb 06 14:46:11 PeterThoeny, that will not save time Feb 06 14:46:25 especially when we come to release 4.0.2 Feb 06 14:46:27 Sven. Except for ONE commit all commits so far has been bugfixes or plugins. And steffen will revert the ONE. So I agree with Peter. Release 4.0.1 and then branch Feb 06 14:46:29 SvenDowideit_: they are _all_ that has been committed since .. let's keep things linear for now, that'll save a lot of time later on Feb 06 14:46:41 SteffenPoulsen, Lavr Feb 06 14:46:41 NO Feb 06 14:46:43 Might we defer to Sven's judgement on this since he's the one who will be doing it? Feb 06 14:46:56 ArthurClemens, already said he has another comiit in there that should not be in 4.0.1 Feb 06 14:46:58 thats 2 Feb 06 14:47:04 and then there could be another Feb 06 14:47:06 and so on Feb 06 14:47:22 nope, he was mention maketexts, they are clear to go in now .. the patch he made needs to go in anyway Feb 06 14:47:24 like i said, we sweated blood to get a repeatable build process Feb 06 14:47:26 but releasing now before branching is less risky Feb 06 14:47:32 no its not Feb 06 14:47:42 the risk is compounded over time Feb 06 14:48:05 and if you thing i'm going to build it without a few test runs Feb 06 14:48:32 there is nothing preventing someone from making a 4.0.1rc mind you Feb 06 14:48:36 ... Feb 06 14:48:36 * MeredithLesly (n=Meredith@proxy.wildwoodweb.net) has joined #twiki_edinburgh Feb 06 14:48:42 hi Feb 06 14:48:51 its simply that a real release should be a real release Feb 06 14:48:56 hi meredith, welcome! Feb 06 14:48:56 moin moin MeredithLesly Feb 06 14:49:02 well, as soon as you do _enhancements_ you add risk clearly, hopefully as long as you _fix bugs_ you minimize risk (?) Feb 06 14:49:08 sorry, not used to these meetings Feb 06 14:49:32 bitc(a|h), hi :-) Feb 06 14:49:36 It sounds like Sven is ready to do the work for doing the branch and testing build. I say let's let him do it. Feb 06 14:49:45 I agree Feb 06 14:49:45 * MeredithLesly is now known as bitca Feb 06 14:49:59 And applaud his commitment to establishing an replicable build and release process. Feb 06 14:50:15 welcome bitca! Feb 06 14:50:47 Perhaps folks could express their reservation with that and allow him to address. Feb 06 14:51:00 or how he's address it in his process. Feb 06 14:51:04 i am ok if sven thinks it does not take more time, is low risk and includes all the fixes we have done so far Feb 06 14:51:06 the short version is that i intend to have something built and uploaded in 12 hours Feb 06 14:51:27 i would like it however if there were more bugs from the list fixed Feb 06 14:51:29 The only concern I have is that all the bug fixes done so far gets into 4.0.1 because most are pretty important. Feb 06 14:51:42 especially to know that the mod_perl things have been looked at Feb 06 14:51:52 Lavr, yep, i agree Feb 06 14:52:01 but only if we tell the user that on the topic Feb 06 14:52:10 they must know what they are getting up front Feb 06 14:52:23 Good. Seems we have agreement. Any further comments on this item? Feb 06 14:52:35 y Feb 06 14:52:42 who is going to look into mod_perl? Feb 06 14:52:42 well, I'll see how fast i can copy & paste bug items -> known issues, not sure I can make them all this evening (i.e. make it for Svens deadline) Feb 06 14:52:57 SteffenPoulsen, dot it using svn log Feb 06 14:53:04 svn log -r123: Feb 06 14:53:18 where you replace 123 with the svn number of the release Feb 06 14:53:42 yep, I'll think of something :-) Feb 06 14:53:47 i'll be doing that too, so don't stress if you don't have time Feb 06 14:54:06 but i prefer to do it to cerify your list Feb 06 14:54:09 verify Feb 06 14:54:25 that's be great :-) Feb 06 14:54:28 if i hadn't slept in, i'd have made it for this meeting Feb 06 14:54:36 on mod_perl, if the issue is only in edit and other non-view scripts, it could be doc only question for 4.0.1 (to "please put only the view script under mod_perl") Feb 06 14:54:44 so we could discus if all of them should go in Feb 06 14:55:07 mmm Feb 06 14:55:16 do we know if view actually works? Feb 06 14:55:27 I have seen save errors even when I ran only "view" under mod_perl. But I have not confirmed if the issue when away after preloading all modules. Feb 06 14:55:29 i couldn't even get mod_perl working Feb 06 14:55:47 as i got twikipath every second view Feb 06 14:55:57 but i don't know if that was twiki / mod_perl Feb 06 14:56:15 SvenDowideit_: a typical sign of incomplete preloading Feb 06 14:56:32 well, kinda :) Feb 06 14:56:42 i recon its a sign that twiki does not do mod_perl Feb 06 14:56:43 well, don't know about mod_perl, but have run speedycgi for a long time on view, with no problems I can think of Feb 06 14:56:59 * bitca is removing mod_perl as we speak Feb 06 14:57:00 as i could not find the docco telling be how to do it Feb 06 14:57:06 I'm not following the mod perl discussion here but am looking at next item. Do you want to comtinue with this tangent? Feb 06 14:57:10 Speedy is much more forgiving. Feb 06 14:57:13 only lots of conflicting things to do Feb 06 14:57:39 please don't mention speedy / fast :) Feb 06 14:57:56 it does not resolve the bug that we have released something that claims to work on mod_perl Feb 06 14:58:04 but its damned hard to get working Feb 06 14:58:09 most people starting out the mod_perl adventure knows what's expecting them .. I think it's cool to just doc it as a "view" thing Feb 06 14:58:19 Peter proposed just a doc change for 4.0.1 Feb 06 14:58:22 We cannot resolve the mod_perl glitches in 4.0.1. It will take time to nail down and may be a matter of recommended configs that are known to work. Feb 06 14:58:39 ok, so no-one will look into it for 4.0.1 Feb 06 14:58:43 roger Feb 06 14:58:44 and leave all other mod_perl code changes to later. Feb 06 14:58:47 y Feb 06 14:59:04 yes, in the interest of a timly release Feb 06 14:59:21 fixes will not hold up the release Feb 06 14:59:27 OK - I think we're ready to move on. Feb 06 14:59:31 but if someone fixes somethign in the next 12 hours Feb 06 14:59:36 they will go in Feb 06 14:59:41 who is doing the doc? Feb 06 14:59:49 which doc? Feb 06 15:00:02 on "only view script under mod_perl" Feb 06 15:00:27 excellent opportunity for Lavr to show his doc patch capabilities? Feb 06 15:00:28 (and testing it to make sure it works :) ) Feb 06 15:00:39 anyone familiar where mod_perl docs exist at present? Feb 06 15:00:49 I think the codev/ModPerl needs some refactoring. I will post my current setup tonight and then maybe we can help each other refactor. Feb 06 15:00:53 there are possibly none Feb 06 15:01:12 but should go into installation guide and upgrade guide Feb 06 15:01:28 even in the Dakar features list? Feb 06 15:01:48 I don't think there is anything in installation guide or upgrade about mod_perl Feb 06 15:01:54 One problem is that mod_perl under Apache 1.3 needs very different config from Apache2. So I do not just want to refactor out the current ModPerl content. Feb 06 15:01:56 perhaps I'm wrong... Feb 06 15:02:32 hmm, good point Feb 06 15:02:36 If there is no such docs in the distributed docs - than it's just a matter of changing a codev topic Feb 06 15:02:43 better to add it to supplemental docs Feb 06 15:02:45 in http://twiki.org/cgi-bin/view/TWiki/InstallingTWiki Feb 06 15:02:49 and moot in relation to the release. Feb 06 15:02:52 and http://twiki.org/cgi-bin/view/TWiki/UpgradingTWiki Feb 06 15:03:14 or even just adding links from those topics to more info on mod_perl... Feb 06 15:03:26 Cairo sucked with mod_perl so I do not think there are much upgrade issues related to this. Feb 06 15:04:02 NOW are we ready to move to next item? Feb 06 15:04:07 ok, add a link in InstallingTWiki, and describe to run only view under mod_perl Feb 06 15:04:17 yes Feb 06 15:04:32 * Lynnwood doesn't mean to appear impatient but there's no easy way to check for group readiness other than ask. Feb 06 15:04:46 OK Feb 06 15:04:53 action item for Lavr? Feb 06 15:04:53 Release focus of EdinburghRelease Feb 06 15:05:00 On this item, I'd like to be clear what we can achieve in this meeting. Feb 06 15:05:00 Option: brainstorm major items of major focus for next release. Feb 06 15:05:17 and then take discussion to a topic after meeting. Feb 06 15:05:19 I will descrive my current mod_perl settings for Apache2 Feb 06 15:05:42 that's great - the "find" approach would be great to have listed as primary option Feb 06 15:05:52 I see little or no chance of reach consensus on focus of edinburgh (in this meeting, that is) Feb 06 15:06:05 lol. No kidding Feb 06 15:06:18 ok, another non edin :) Feb 06 15:06:33 the goal of this meeting is to agree on process and timeline to decide on EdinburghRelease focus Feb 06 15:06:46 Ah, meta agenda Feb 06 15:06:47 Ah Feb 06 15:06:48 shall i make a twiki04x00 branch, or a twiki04 branch? Feb 06 15:06:52 http://twiki.org/cgi-bin/view/Codev/EdinburghRelease#Release_Focus Feb 06 15:07:07 sven can we talk later? Feb 06 15:07:14 for me, i will have to ignore most of the edin* stuff Feb 06 15:07:19 as its simply too soon Feb 06 15:07:30 until we have bugs fixed Feb 06 15:07:39 understood. Feb 06 15:07:48 (i don't want to stop you guys from talking / deciding though) Feb 06 15:08:10 Peter - do you have thoughts/proposal for process & timeline for deciding Edinburgh focus? Feb 06 15:08:19 focus looks good as a draft and some people are updating their personal roadmaps at present, which is a good start, I believe Feb 06 15:08:32 * bitca imagines this is a bit like herding cats Feb 06 15:08:50 how about: one week for all to brainstorm on codev.edinburghrelease topic Feb 06 15:08:53 cats are disciplined sheep in comparison... Feb 06 15:08:57 discuss on next week meeting Feb 06 15:09:02 and decide in two weeks Feb 06 15:09:26 at first brush, that seems too quick. Why so soon? Feb 06 15:09:35 that's pushy, but it needs to be done .. especially if we are going for a timeframe less than a year for Edin Feb 06 15:09:53 I guess this begs some discussion of timeframe for Edin. Feb 06 15:09:57 i'd love to suggest 2 weeks post cdot being back :) Feb 06 15:10:01 6months? Feb 06 15:10:16 6 months for Edin release? Feb 06 15:10:18 Reading the ambition, TWiki seriously needs more developers Feb 06 15:10:21 when is crawford back? Feb 06 15:10:36 end of this week i think Feb 06 15:10:46 unless he get stuck in a bog Feb 06 15:10:47 I'm assuming developers don't get paid? Feb 06 15:10:53 I think we need to think more Roadmap than Edinburg. What do we want in 4.1? What in 4.2? What in 5.0? Instead of these big revolutionary release that take 1.5 years to reach. Feb 06 15:10:54 correct ish Feb 06 15:10:58 ArthurClemens: indeed a limiting point Feb 06 15:11:29 my take: we don't decide up front, we decide a date, and a focus Feb 06 15:11:39 and whatever is of release quality get released Feb 06 15:11:44 good point on 4.1 vs 5.0 Feb 06 15:11:56 And roadmap means: decide what is most important Feb 06 15:11:59 and depending on what that is, tells us if its 4.1 or 5 Feb 06 15:12:03 Yes. Since cleaning things up/refactoring can be an ongoing process Feb 06 15:12:08 trouble with roadmap Feb 06 15:12:19 is that it depends on people finishing the work Feb 06 15:12:27 So perhaps we should really focus on roadmap discussion as context for planning next release? Feb 06 15:12:29 true Feb 06 15:12:33 ie holding up a release indefinatly until the roadmap is done Feb 06 15:12:37 * bitca imagines some twisty roundabout Feb 06 15:13:05 whereas if we go for very generic direction, and a date Feb 06 15:13:08 In OSS projects roadmaps are mainly driven by who want to work on something and not what money can we get from it. Feb 06 15:13:26 we have a chance of releaseing Feb 06 15:13:36 But it is still good to have a plan so people know what to expect and how to help. Feb 06 15:13:37 That works better if people are students or are paid by their employers to work on OSS Feb 06 15:13:41 a roadmap works well in for profit projects Feb 06 15:13:49 Spending some time of creating a "good enough" roadmap would help provide context for releases. Feb 06 15:14:04 Yep, a great roadmap can make the difference between having a chance on attracting developers or not Feb 06 15:14:05 i am concerned that we spend time on a nice roadmap and then it gets put aside Feb 06 15:14:07 A roadmap also tells us what to focus on most when we must choose Feb 06 15:14:08 Not a "written in stone" roadmap Feb 06 15:14:08 Lynnwood, y, i'd call that a general direction Feb 06 15:14:10 :) Feb 06 15:14:15 yes Feb 06 15:14:17 A pathmap? Feb 06 15:14:20 roadmaps mostly are Feb 06 15:14:24 stone ish Feb 06 15:14:32 PeterThoeny, yep Feb 06 15:14:40 That is, a dirt-roadmap? Feb 06 15:14:41 really what DEVELOP was about Feb 06 15:14:47 was no roadmap Feb 06 15:14:53 ability to create some kind of roadmap most a function of focus and setting deadline for that. Feb 06 15:14:55 that is why i favor a focus that is just a guideline for developers Feb 06 15:14:56 A Roadmap for OSS is more list of features and they get on the map as people commit to do them. Feb 06 15:15:00 i.e. not an open-ended wiki discussion. Feb 06 15:15:01 it was more to do with allowing people to do what they wanted / needed Feb 06 15:15:26 I get confused by "user centric features". Feb 06 15:15:26 ok, i see the point Feb 06 15:15:32 we found that people commiting do do them was inneffectual Feb 06 15:15:40 as people come and go mid way Feb 06 15:15:48 The page shows technology centric features Feb 06 15:15:54 y :( Feb 06 15:16:05 hey I rep-resent that statement! Feb 06 15:16:13 ;-) Feb 06 15:16:14 so a roadmap is more or less just an organized and prioritized enhancement request list Feb 06 15:16:18 "innovation with compatibility in mind"... semi-oxymoronic? Feb 06 15:16:19 which is the reason that the bugs web does not have an assigned to field Feb 06 15:16:56 So how about planning discussion of roadmap for next month? Feb 06 15:17:00 arthur: user centric vs developer centric Feb 06 15:17:06 I strongly endorse a 4.1 focus with an eye to 5.0 Feb 06 15:17:12 dakar had a lot of developer centric focus Feb 06 15:17:30 but "Syncronous edits, OO content access syntax" ? Feb 06 15:17:38 seems developish Feb 06 15:17:42 it is Feb 06 15:17:42 user centric vs developer centric is a rather starved arguement, imo Feb 06 15:17:55 y Feb 06 15:18:03 and slippery Feb 06 15:18:03 unless we get some non-developer developers Feb 06 15:18:04 Peter, could you share your gained knowledge first? Feb 06 15:18:13 Wikis in the workplace Feb 06 15:18:17 I'm kind of a non-developer developer Feb 06 15:18:21 sync edit, oo content access syntx is user centric since it is for the users/customers Feb 06 15:18:25 let's just make case for features we want to see and stop labeling them. Feb 06 15:18:34 as either/or Feb 06 15:18:53 user == users and external developers of twiki Feb 06 15:18:57 users/customers: company developers Feb 06 15:19:00 OSS is always developer centric by nature. What still drives OSS to high quality is that we all want people to like what we are doing. And that is actually a stronger motivation that being paid. Feb 06 15:19:03 developers == twikicommunity developers Feb 06 15:19:07 or commitment one way or another will be measured by what actually achieve rather than how we lable them. Feb 06 15:19:18 But __users__ ? Feb 06 15:19:19 s/or/our Feb 06 15:19:35 Like people using an intranet Feb 06 15:19:46 arthur: suggestion fo better word? Feb 06 15:19:55 customers? Feb 06 15:19:59 Two classes of developers: those developing TWikiApplications, and those developing plugins Feb 06 15:20:10 (third class, working on TWiki engine, i guess) Feb 06 15:20:14 ArthurClemens: yep, not like users == people downloading TWiki and installing on intranet Feb 06 15:20:22 client developers Feb 06 15:20:36 bitca, i fall into the works on core code to make the TWikiApps he's making work group Feb 06 15:20:47 designers? Feb 06 15:21:04 designers==client developers, i mean Feb 06 15:21:12 all discussions about what the users want is hypothetical. We have no user surveys or even a marketing department to tell us. Feb 06 15:21:35 That's why I was asking Peter about his interviews Feb 06 15:21:40 Other than the general "ease-of-use" and "speed" Feb 06 15:21:44 and in the end, what get's done depends on a willing developer to implement. Feb 06 15:21:55 "no user surveys or even a marketing department to tell us" sounds like a company I know. Feb 06 15:21:56 y Feb 06 15:21:59 Lynnwood: We get bugreports and feedback in Support and Codev Feb 06 15:22:03 So in the end, all we have to prioritize features is people making a case for it. Feb 06 15:22:18 even that is dubious Feb 06 15:22:27 as i'll be working on what i work on Feb 06 15:22:38 steffen: that feedback we get is good feedback from admin users Feb 06 15:22:50 we miss feedback from managers and decision makers Feb 06 15:22:54 * bitca wonders how any OSS gets out of beta, or even alpha Feb 06 15:22:54 and labeling it a "developer" or "user" feature adds little. (particularly given the distinction has become a "hot button" issue) Feb 06 15:23:01 which for now is UserDotPm modules Feb 06 15:23:03 so market focus is important Feb 06 15:23:08 in oder to succeed Feb 06 15:23:26 i created http://twiki.org/cgi-bin/view/Codev/ProcessForMarketDrivenInnovation Feb 06 15:23:26 yes - if we had actual data about that. Feb 06 15:23:51 Look at succesful apps like Basecamp Feb 06 15:23:53 as a starying point to dicuss how we should handle the marketing side of things Feb 06 15:24:04 37signals has a clear view of simplicity Feb 06 15:24:25 they obviously deal with use scenarios Feb 06 15:24:32 "Strengthen TWiki as an application platform" sound like a VeryGoodThing Feb 06 15:24:37 'what if the user'... Feb 06 15:24:39 probably the best directors we have on that is to copy features from JotSpot, confluence, Basecamp - because they DO have marketing folks to provide that focus. Feb 06 15:24:53 I say this only half-jokingly. Feb 06 15:24:58 And users to provide feedback Feb 06 15:25:01 good point Feb 06 15:25:02 not admins only Feb 06 15:25:41 we could propell twiki _way more_ if we tune the marketing message Feb 06 15:25:46 this is a low hanging fruit Feb 06 15:25:49 If I look at my own company: attachments are not secure, so no TWiki Feb 06 15:25:58 this data is very easy to get Feb 06 15:26:10 Isn't an overweening (right word?) question "Why TWiki instead of another Wiki/CMS?" Feb 06 15:26:17 thanks for the reminder :) Feb 06 15:26:48 ok, important discussion, and we degressed Feb 06 15:27:04 i'd like to trial moving the pub dir and the template dir into the data data dir Feb 06 15:27:08 could be part of the roadmap discussion.... Feb 06 15:27:15 ie, attachements and templates become topics Feb 06 15:27:26 The thing is "marketing dept" can be replaced by good user feedback Feb 06 15:27:29 and then we move auth out of band Feb 06 15:28:17 move stuff out of bad has its issues, but that is for anotehr time Feb 06 15:28:25 another option would be to do feature comparison between twiki and competition on usability and interface matters. Feb 06 15:28:37 its part of my personal road map Feb 06 15:28:37 Who do we imagine are users are now, who might be new users, why do they want to use TWiki? Feb 06 15:29:02 I wonder, what does "to succeed" really mean in our context? .. attracting developers from other wikis and speeding up development? Feb 06 15:29:06 Why *would* they want to use TWiki if we did x,y,z Feb 06 15:29:06 and than set targets to catch up in those areas. Feb 06 15:29:24 but i do think that its a twiki-sd thing unless it is finished and proves to be a useful thing Feb 06 15:29:24 building up a huge end-user base, dealing with lots of support issues? Feb 06 15:29:31 "to succeed" means "providing something valuable" Feb 06 15:29:36 I think Lynnwood and I are roughly on the same page Feb 06 15:29:43 bitca - yes Feb 06 15:29:48 "providing something valuable" Feb 06 15:29:50 yep Feb 06 15:30:18 makes sense .. "valuable to end users" Feb 06 15:30:22 (overweening was definitely the wrong word) Feb 06 15:30:25 anadotally - in most reports about comparisons, it's the usability and polish factors that were killers for TWiki. Feb 06 15:30:37 It is also important that a product knows its segment and what is wants to focus on - so that there is a difference between TWiki and the other Wikis. A good difference. Feb 06 15:30:44 Overarching Feb 06 15:31:04 how about having a better interface for handling metadata? Feb 06 15:31:07 Killed using TWiki, or killed the competition? Feb 06 15:31:11 trying to get back to focus of current discussion item. Feb 06 15:31:12 this would help in many areas Feb 06 15:31:18 killed twiki Feb 06 15:31:53 like setting parent topic easily Feb 06 15:31:58 How about putting focus on Roadmap for next month - and then revisit Edinburgh focus? Feb 06 15:32:02 or provide folksonomie Feb 06 15:32:10 There's a wide gap between tiny end-user base and huge end-user base Feb 06 15:32:35 roadmaps til march, release in july Feb 06 15:32:47 Who do you/we *want* to be the users? other than ourselves? Feb 06 15:32:53 my take: roadmaps are not for a release Feb 06 15:32:56 they are longer term Feb 06 15:33:01 lynnwood, i think it should be the other way around first decide on a high level focus, then use that to prioritize the roadmap Feb 06 15:33:03 and thus ever changing Feb 06 15:33:23 and not detailed at all Feb 06 15:33:27 Sven. roadmaps till March, releases all the time. So that you never have to be frustrated that it takes 18 months till next release. Feb 06 15:33:28 Peter - "High level focus" = Edin focus? Feb 06 15:33:36 yep Feb 06 15:33:48 18 months is horrid Feb 06 15:33:56 yes, high level focus for edinburgh (every major release had a focus so far) Feb 06 15:33:56 i still haven't updated the debian package Feb 06 15:34:08 what was twiki-4? Feb 06 15:34:19 The discussion will be hugely different depending on who you want the users to be Feb 06 15:34:50 hmmm. that's the opposite to my sense of it. Seems like the road-map is the "high level" and Edin is next stop in that general direction. Feb 06 15:35:24 sven: twiki 4: code refactor, code refactor, code refactor, mod_perl, speed improvements Feb 06 15:35:34 * SamHasler|Away is now known as SamHasler Feb 06 15:35:37 there is a difference between the roadmap to twiki4.1 and the twiki roadmap Feb 06 15:35:45 ta :) Feb 06 15:35:50 twiki 5: more code refactor, more code refactor, more code refactor Feb 06 15:35:57 for me the focus was to deprecate the core group Feb 06 15:36:00 twiki 4.1: mod_perl (?) Feb 06 15:36:23 bitca: excellent suggestion :-) Feb 06 15:36:24 mixed success Feb 06 15:36:42 twiki 5: TML replaced by extended XHTML Feb 06 15:36:45 And haven't I heard that 4.0 is *slower* than 3.0? Feb 06 15:36:45 I also have a sense that there's some resistance to addressing roadmap - so I think if we go to Edin focus first, the roadmap discussion won't happen. Feb 06 15:37:04 How do you know how to get there if you don't know where you're going? Feb 06 15:37:26 good question bitca Feb 06 15:37:34 that is why we need market focus Feb 06 15:37:57 my sense of TWiki roadmap is it list some general direction for next few releases and each release focuses on some aspect of that. Feb 06 15:38:02 When I contribute to the roadmap topics I would say. 4.1 - incremental speed improvements and better WYSIWYG. And 5.0 redesign topic storage to something indexed that than scale much better then today where Twiki clearly has an "upper limit" defined by speed of searches. Feb 06 15:38:22 Lvar and I (and others?) are kind of users more than developers of TWiki, methinks Feb 06 15:38:46 I think I fall under that gorup as well. Feb 06 15:39:01 So we do, to some extent, have users amongst us Feb 06 15:39:09 I'm closer to user than developer - dispite the company I keep. Feb 06 15:39:41 We are users who are willing to go through more pain than most, perhaps Feb 06 15:40:09 So it seems we have different definitions of "roadmap" here. Feb 06 15:40:35 Well the TWiki community is a nice community where oppinions are received in a positive way - even when there is disagreement. Feb 06 15:40:36 given that, I don't see how we can have agreement about which discussion to have first. Feb 06 15:41:06 well, I believe it's excellent .. both targets, wysiwyg + mod_perl takes test test test, so perhaps a better (automated) testing framework could be part of the plan as well Feb 06 15:41:29 and given that, let's just try to set a target date for Edin release focus. Feb 06 15:41:42 and hope some roadmap discussion continues. Feb 06 15:41:45 And then get more detailed about 4.1 focus? Feb 06 15:42:07 on roadmap vs high level focus of edinburgh, do we have a conclusion? Feb 06 15:42:21 no - that's what I'm saying Feb 06 15:42:33 and I'm not sure we can reach consensus here. Feb 06 15:42:44 I don't think there has to be a "vs". Feb 06 15:43:05 To some extent, it appears that the more userish here are leaning towards clarifying who the users will be and what they will want Feb 06 15:43:12 only if we think one can provide context for the other. (which I do) Feb 06 15:43:43 I see two different scopes. 1. Which features when. That is roadmap. 2. HOW. That is deciding on development model, branching, documentation model. Feb 06 15:43:55 I prefer to call it "focus". Users fit in well here. Feb 06 15:44:00 And I think 2 is urgent to get settled. Feb 06 15:44:38 I suspect that 1 and 2 involve different (overlapping) sets of people Feb 06 15:44:40 "Focus" means: finding what is missing, where lie the strengths. Feb 06 15:44:49 I think to decide about a final roadmap, we have to see what Crawford as the main developer says Feb 06 15:44:58 but good to have some ideas about it Feb 06 15:45:05 Roadmap has the connotation of directive Feb 06 15:45:13 Personally, I don't care all that much about 2, not being a core developer (as long as it works) Feb 06 15:45:46 OK, since we do not have a consensus on what "roadmap" is, perhaps let's just return to timeframe for deciding Edinburgh focus. Feb 06 15:45:49 we should kick namings like "core developer" anyway Feb 06 15:45:52 In the end we will have some participants in the focus/roadmap, and some out of it Feb 06 15:46:21 OK. I'm a doc/maybe-some-plugin/Application person Feb 06 15:46:45 I guess poor Sven is shove-it-out-the-door person Feb 06 15:46:49 core user :-) Feb 06 15:46:55 =P Feb 06 15:47:01 maybe :) Feb 06 15:47:10 yeah, core user is ok for me Feb 06 15:47:10 its a role i do in most places i work Feb 06 15:47:17 aside: without core community members involvement/commitment to creating roadmap, it has absolutely no use. Feb 06 15:47:19 as i automate Feb 06 15:47:37 Agreed, because without commitment, nothing happens Feb 06 15:47:42 it depends if you want _everybody_ in Feb 06 15:47:50 So back to timeframe for deciding Edin. focus. Sven proposed March I believe. Feb 06 15:47:52 thats why i started the personal roadmaps Feb 06 15:48:01 Sven is committed, no doubt, but with other focus Feb 06 15:48:23 (after 4.01, "should be committed?") Feb 06 15:48:31 * Lynnwood believe very strongly that the sum of the individual roadmaps won't add up to a TWiki roadmap. Feb 06 15:48:52 people are generally commited to their personal things, and to leverage that, we can combine the personal ones into a realistic release proposal Feb 06 15:49:15 Perhaps, in wiki-fashion, we could each enumerate what we'd like to see in TWiki 5.0 (and 4.1 as well?)? Feb 06 15:49:19 * SvenDowideit_ beleives anything not on a personal roadmap is unlikly to get done in a timely fashion Feb 06 15:49:22 And then refactor? Feb 06 15:49:25 * PeterThoeny thinks that personal roadmaps are good to know where the interests are, but they distract from focus unless coordinated Feb 06 15:49:40 Crawford as the leading person in the development process is not a member of the "TWiki Core Team"... Feb 06 15:50:01 !!! Feb 06 15:50:03 a personal roadmap is simply telling you what i'm actually focussing on, rather than what you would like me to focus on Feb 06 15:50:11 andre: please ask crawford Feb 06 15:50:15 a shared roadmap implies some give and take and shared consensus. Feb 06 15:50:36 very different process from me just listing what I want. Feb 06 15:50:45 We each probably have personal roadmaps. Making them explicit and looking for commonalities might facilitate discussion? Feb 06 15:50:46 Lynnwood, yep Feb 06 15:50:57 bitca, i think so Feb 06 15:51:13 as its a begining Feb 06 15:51:16 So perhaps the *first* date is a deadline for laying out our personal roadmaps? Feb 06 15:51:17 Peter, maybe the whole role structure has to kicked Feb 06 15:51:20 anyway... the only item I can see to try for consensus here is a target date to settle Edin. fucus. Feb 06 15:51:30 it makes no sense Feb 06 15:51:33 * bitca coughs, not necessarily Feb 06 15:51:34 s/fucus/focus Feb 06 15:51:50 A *short* deadline for personal roadmaps Feb 06 15:52:10 (s/roadmaps/goals and wishes/) Feb 06 15:52:35 so proposed: to settle on the focus for Edinburgh release by March 1. Feb 06 15:52:38 And then merge/purge to achieve a shared roadmap? Feb 06 15:53:10 TWiki 5: role structure kicked in favour of community orientated structure Feb 06 15:53:18 lol Feb 06 15:53:30 But, yeah. Feb 06 15:53:33 yes :) Feb 06 15:53:37 as much as I care about the roadmap discussion, I'd like to defer that for now. Feb 06 15:53:51 And can we hold the discussion about structure for right now? Feb 06 15:53:58 march 1st is 3.5 weeks from now Feb 06 15:54:03 i'd like to shorten that Feb 06 15:54:16 why? Feb 06 15:54:49 while he's answering that, perhaps we could get quick poll on what others think about March 1 date. Feb 06 15:54:57 to keep the momentum going and to enable folks to work in a coordinated way Feb 06 15:55:11 1 = you don't like it (either to soon or not soon enough) Feb 06 15:55:17 5= you like it. Feb 06 15:55:20 March 1 means that we will start writing Feb 28 Feb 06 15:55:20 i'd go for feb 20 Feb 06 15:55:28 * legolas (n=chatzill@chello084115142036.6.graz.surfer.at) has joined #twiki_edinburgh Feb 06 15:55:51 If by focus you mean something concise like "Strengthen TWiki as an application platform" Feb 06 15:56:00 earlier seems quite feasible Feb 06 15:56:34 I would see folks adding comments to the Edinburgh topic (and to personal roadmaps if desired) and we'd discuss it over next 3 weekly meetings. Feb 06 15:56:38 yes, high level focus is all that's needed Feb 06 15:56:52 Do not forget that February will also be a month of more bugs and more bug fixes. And helping people getting their old plugins working. Feb 06 15:57:00 for comparison, http://twiki.org/cgi-bin/view/Codev/CairoRelease had Feb 06 15:57:07 1. A more capable plugin system. This might include developments that avoid (significiantly) more time processing pages as more plugins are added. Feb 06 15:57:09 Nonetheless, if the focus is, well, focused, it shouldn't take 3.5 weeks Feb 06 15:57:13 2. EnhancedSkinHandling Feb 06 15:57:21 3. Apache 2.0 updates Feb 06 15:57:28 4. Perl 5.8 updates Feb 06 15:57:31 and bug fixes Feb 06 15:57:47 OK right now I'm only hearing votes for shorter timeframe. Feb 06 15:57:55 How do folks feel about Feb 20? Feb 06 15:58:04 I vote for Feb 20 Feb 06 15:58:05 2 weeks. Feb 06 15:58:07 me too Feb 06 15:58:13 no prob Feb 06 15:58:15 I'm good with that. Feb 06 15:58:22 OK with 20th Feb 06 15:58:24 5. kick the roles concept and reflect the real community of TWiki Feb 06 15:59:01 I think the motion is carried Feb 06 15:59:25 Any disenting sentiments? Feb 06 15:59:54 If not, then I think we're agreed... Feb 06 16:00:06 I'd like to point out that the focus for Dakar was pretty minimal (if not minimal to achieve) Feb 06 16:00:24 Oh, sorry, Cairo Feb 06 16:00:30 I'd like to do a time check here: we're already at 2 hours and have 2 more items to discuss. Feb 06 16:00:53 possibility I don't sit this out Feb 06 16:01:01 bedtime here Feb 06 16:01:11 Not sure how much longer I can go. but will stay as long as I can. Feb 06 16:01:18 only 6 pm here Feb 06 16:01:19 bitca: the first tow points have been very essential Feb 06 16:01:28 and helped twiki Feb 06 16:01:47 OK, moving ahead... Feb 06 16:01:59 Split DEVELOP branch Feb 06 16:02:04 I'm not trying to minimize them. sorry if it seemed so Feb 06 16:02:07 opening comments on this. Feb 06 16:02:21 (that's an invitation) Feb 06 16:02:35 * bitca doesn't know what that even means. Sorry. Feb 06 16:02:47 * Lynnwood doesn't either. Feb 06 16:02:59 actually, guess I do. Feb 06 16:03:06 As the user-developers fade into the sunset... Feb 06 16:03:08 i think there is pretty much consenus on http://twiki.org/cgi-bin/view/Codev/OneSvnBranchPerRelease Feb 06 16:03:27 so what do we need to discuss on this item? Feb 06 16:03:39 just celebrate that consensus? Feb 06 16:03:39 This is similar to the Debian model? Feb 06 16:03:41 two questions open Feb 06 16:03:43 1. when Feb 06 16:03:52 2. who is doing the merge Feb 06 16:04:02 (in an ongoing manner) Feb 06 16:04:23 Oh, slightly alternative suggestion, as debian does: Feb 06 16:04:29 Sounds like Sven is ready to do #1 now. Feb 06 16:04:33 Debian has stable, testing, unstable Feb 06 16:05:05 I'm willing to use testing, but not unstable, since I have customers Feb 06 16:05:12 Do we still have Svn here or has he gone for more coffee? Feb 06 16:05:24 * bitca now knows where svn got its name Feb 06 16:06:01 Is the Debian model to difficult to implement? Feb 06 16:06:11 s/to/too/ Feb 06 16:06:55 Oh, that's addressed by the "incrementally merge...does not work", i guess. Sigh Feb 06 16:06:55 ok, my current intent is to create a TWiki04 branch Feb 06 16:07:00 it is probably not dificult to _implement_ but is takes precious resources to maintain three branches Feb 06 16:07:06 and to merge them Feb 06 16:07:21 The problem is that anyone who has customers (paying or not) has to stick with Dakar Feb 06 16:07:54 (like me) Feb 06 16:08:10 TWiki04 branch == stable Feb 06 16:08:16 what are the three branches? Feb 06 16:08:16 DEVELOP == unstable Feb 06 16:08:30 testing was introduced into debian due to the huge number fo packages Feb 06 16:08:35 and interdependancies Feb 06 16:08:40 In Debian, there's a third, which is the relatively stable portion of unstable Feb 06 16:08:43 so we don't need to go there yet Feb 06 16:08:54 And because stable was so out-of-date Feb 06 16:08:58 what we do need Feb 06 16:09:35 is a hard, simple and totally obvious way to determine which things get merged from DEVELOP into TWiki04 branch Feb 06 16:10:04 mmm, i think that makes it clear that it should be a TWiki04x00 branch Feb 06 16:10:05 The minute you branch - every bug fix must be done twice. The more you deviate between the two the more work it is. At one point you have to give up. Feb 06 16:10:09 that will keep focus Feb 06 16:10:09 TWiki04 < TWiki04.1 < TWiki05 Feb 06 16:10:17 Lavr, yep Feb 06 16:10:35 once there is sufficient deviation, thats another trigger for a new release Feb 06 16:10:49 these things a a positive thing Feb 06 16:10:57 are a Feb 06 16:11:15 The question is, is 4.5 closer to 4 or 5? Feb 06 16:11:27 s/The/A significant/ Feb 06 16:11:33 its unlekely that we get to a 4.5 Feb 06 16:11:43 I was picking an arbitrary number Feb 06 16:11:49 basically, if the question comes up, its a reason to call it a 5 Feb 06 16:12:02 could we have a way to tag closed bugs that should be merged into Dakar? Feb 06 16:12:04 again, its a trigger Feb 06 16:12:10 yes Feb 06 16:12:16 why not keeping it simple with just two branches: Feb 06 16:12:16 i mean Feb 06 16:12:16 no Feb 06 16:12:28 1. 4.0 maintenance branch (dakar) Feb 06 16:12:30 yep - DEVELOP & TWiki04x00 Feb 06 16:12:37 2. edinburgh branch Feb 06 16:12:44 Does a significant minor release become a major release even if it doesn't match the goals? Feb 06 16:12:55 Lynnwood, a tag in bugs to merge to the TWiki04x00 branch Feb 06 16:13:06 bitca, IMO yes Feb 06 16:13:09 that's what I meant. Feb 06 16:13:19 :) see my pet ant? Feb 06 16:13:39 I think the next month it will be the exception that a bugfix will not be in 4.0 Feb 06 16:13:43 ? Feb 06 16:13:52 Enhancements go to 4.1 Feb 06 16:14:06 sven: DEVELOP and TWiki04x00 is different from the proposal in http://twiki.org/cgi-bin/view/Codev/OneSvnBranchPerRelease Feb 06 16:14:16 isn't DEVELOP == Edinburgh == HEAD? Feb 06 16:14:26 SamHasler, i think so Feb 06 16:14:28 We're giving HEAD now? Feb 06 16:14:38 that one talks about twiki/branches/Dakar and twiki/branches/Edinburgh Feb 06 16:14:39 * bitca apologises Feb 06 16:14:41 definaly Feb 06 16:14:52 funnily enough I've just finished reading the SVN book today for work Feb 06 16:15:00 PeterThoeny, y, it does, but thats unmanageble Feb 06 16:15:11 i am just trying to understand Feb 06 16:15:23 the branch needs to be derived from the release name Feb 06 16:15:30 ie automatable again Feb 06 16:15:33 Well, yes. Feb 06 16:15:50 I need to stick to 4.0 until 4.1 is released, at least for my client TWikis Feb 06 16:16:00 My crystal ball says that there is a 4.0.2 before end of this month. Feb 06 16:16:29 if i understand correctly, DEVELOP is always the work in progress branch Feb 06 16:16:34 i agree with Lavr Feb 06 16:16:40 i suspect next week Feb 06 16:16:54 yep, what Sam said Feb 06 16:16:56 The problem is that there are two kinds of work-in-progress: 5.0 stuff and 4.x stuff Feb 06 16:16:56 isn't DEVELOP == Edinburgh == HEAD? Feb 06 16:16:59 yeah, I think we should drop the name develop and just can it HEAD Feb 06 16:17:03 and at points a TWiki04x00 , TWiki04x01 TWiki05x00 branch is created Feb 06 16:17:14 no Feb 06 16:17:34 there will only ever be braches for 4 and 5 Feb 06 16:17:57 How do users know when it's safe to upgrade their 4.x installations? Feb 06 16:18:19 you tag the 4.0.0 release and then develop 4.0.1 on the 4.0 branch, and tag it when it's done Feb 06 16:18:32 I do not think a 5.0 is needed before you have a roadmap type major feature is defined and committed. Right now - what people are jumping on working on in the near future is enhancements. Not revolutions. Feb 06 16:18:43 So I don't do an svn 4.0 update until it's tagged? Feb 06 16:18:46 SamHasler: tags and branches are the same in SVN? Feb 06 16:18:54 yes Feb 06 16:18:58 don't worry Feb 06 16:19:08 DEVELOP will continue as HEAD for a while at lease Feb 06 16:19:09 least Feb 06 16:19:12 be happy? Feb 06 16:19:20 My convention a tag is frozen, a branch is not, but they are the same in SVN. Feb 06 16:19:21 essentially yes, it's a convention of how you intend to use them Feb 06 16:19:33 the extra effort for TWiki04x00 branch merging will be borne by me for a little while Feb 06 16:19:40 and then i will probably script it Feb 06 16:19:41 sven: did i describe what you intend correctly? Feb 06 16:19:44 using the bugs tag Feb 06 16:19:55 tags should never be altered once they are created, they are a reference for a release Feb 06 16:20:11 SamHasler, svn tags are weird Feb 06 16:20:13 SamHasler: What is typically called a baseline? Feb 06 16:20:30 i will be creating a tag for the release in the tags dir Feb 06 16:20:45 it does not affect the DEVELOP branch at all Feb 06 16:20:51 it made sense in the book, but then I've got no CVS history to confuse me Feb 06 16:21:19 Bleh. Just document how to use svn to achieve the desired goal and be done with it. Feb 06 16:21:21 strictly speeking DEVELOP isn't a branch, it's the trunk Feb 06 16:21:34 SamHasler: Just use the word "baseline" whenever you want to say "tags" .. it'll work .. it's something you can always revert to or use as a references easily Feb 06 16:21:40 so returning to the discussion item.... what needs to be settled on this topic this afternoon? Feb 06 16:22:03 i still do not know what model we are going to use Feb 06 16:22:06 PeterThoeny, i think so, but i'm not sure Feb 06 16:22:13 I'm still unclear what 4.1 is Feb 06 16:22:16 the one described in http://twiki.org/cgi-bin/view/Codev/OneSvnBranchPerRelease or what? Feb 06 16:22:22 bitca, it is non-existant Feb 06 16:22:31 OH Feb 06 16:22:32 and thus undefined Feb 06 16:22:33 I should have said TRUNK == DEVELOP == Edinburgh earlier, not HEAD Feb 06 16:22:42 So it's always 4.0 or 5.0? Feb 06 16:22:43 TRUNK == HEAD :) Feb 06 16:22:47 no Feb 06 16:22:51 5.0 is undefined too Feb 06 16:23:00 5.0 is development, i thought Feb 06 16:23:04 no Feb 06 16:23:09 we have 4.0.0 Feb 06 16:23:12 Then i'm hugely confused Feb 06 16:23:13 we are planning 4.0.1 Feb 06 16:23:20 and we are planning a future release Feb 06 16:23:31 sven: at what time in devdo you create a TWiki04x01, TWiki04x02, TWiki05.x00? Feb 06 16:23:34 yet to be decided if its a 4.1, a 5.0 or whatever Feb 06 16:23:45 Aren't 4.0.x releases just bug-fixes? Feb 06 16:23:45 PeterThoeny, i don't know yet Feb 06 16:23:48 has a 4.0 branch been created yet and 4.0.0 tagged? Feb 06 16:23:51 i'm waiting to be able to discuss it Feb 06 16:24:05 i'm waiting to be able to discuss it Feb 06 16:24:37 we know that DEVELOP is the continuing HEAD, TRUNK, whatever Feb 06 16:25:05 we know that a release has been made, and thus i will create a http://svn.twiki.org:8181/svn/twiki/tags/TWikiRelease04x00x00 Feb 06 16:25:28 we also know we need to make a branch to do the 4.0.x work Feb 06 16:25:34 which i propose is either Feb 06 16:25:40 http://svn.twiki.org:8181/svn/twiki/branches/TWiki04 Feb 06 16:25:43 or Feb 06 16:25:45 http://svn.twiki.org:8181/svn/twiki/branches/TWiki04x00 Feb 06 16:25:56 The latter Feb 06 16:25:58 and i'm leaning towards 04x00 Feb 06 16:26:12 Latter. Feb 06 16:26:28 motion carried. moving along... Feb 06 16:26:46 ok, looks workable Feb 06 16:26:49 the point at which that branch is made == when it becomes necessary, due to DEVELOP containing changes that we would prefer not to have in the next 0.01 release Feb 06 16:26:57 which we have reached Feb 06 16:27:07 hmm, I hadn't realised we have a DEVELOP branch http://svn.twiki.org:8181/svn/twiki/branches/DEVELOP/ what does that make trunk? Feb 06 16:27:08 for eg Feb 06 16:27:17 i like the one and only one trunk since this makes it easier do solve the documentation model Feb 06 16:27:19 OK, then this discussion item is complete. Feb 06 16:27:25 trunk == dead, and will be discussed at another date Feb 06 16:27:39 no Feb 06 16:27:39 fairy nuff Feb 06 16:27:47 as i don't have the time to think hard about it this week Feb 06 16:28:23 sven: could you upddate http://twiki.org/cgi-bin/view/Codev/OneSvnBranchPerRelease accordingly? Feb 06 16:28:38 One mostly documentation thing is to deal with which plugins work with which release Feb 06 16:28:40 y Feb 06 16:29:00 mm Feb 06 16:29:07 plugins are also branched Feb 06 16:29:30 We have a ton of plugins that do not work with Dakar and are cluttering up my configuration and visual space Feb 06 16:29:34 ok, can that be added to next weeks agenda? Feb 06 16:29:47 DEVELOP is free for all Feb 06 16:29:51 good! Feb 06 16:29:55 plugin incompatibilities are a _major_ issue we need to avoid Feb 06 16:30:13 Except that many-to-most of the plugins do not work with Dakar Feb 06 16:30:15 So it can't be avoided Feb 06 16:30:34 plugin discussion added to agenda for next meeting. Feb 06 16:30:38 bitca: yes, if the plugin author does some extra work Feb 06 16:30:56 OK, if you prefer: live versus dead plugins Feb 06 16:31:14 On to "Fix Dakar documentation model"? Feb 06 16:31:27 From a USERs point of view - it would be a strength to TWiki as a product if people would focus more on fixing plugins the next month instead of rushing to implement new features to the core. Feb 06 16:32:05 good point kenneth! Feb 06 16:32:06 Lavr, i agree Feb 06 16:32:15 on documentation model: Feb 06 16:32:18 And, for that matter, documenting how to fix plugins (when it can be) Feb 06 16:32:27 if we can focus on bug fixing this month i'd be happier Feb 06 16:32:33 i spend many days brushing up the tWiki web on twiki.org Feb 06 16:32:41 in preparation of the new doc model Feb 06 16:32:55 Um, what does "documentation model" mean? Feb 06 16:33:04 i think my opinion is well known - if its not in svn, it is supplementory Feb 06 16:33:08 that web has now three types of docs: Feb 06 16:33:16 1. distribution docs Feb 06 16:33:21 2. supplemental docs Feb 06 16:33:27 3. historical docs Feb 06 16:33:34 there are also "engine room" docs Feb 06 16:33:42 (for internal use) Feb 06 16:33:43 how are they organized? Feb 06 16:34:04 each topic includes a header and footer Feb 06 16:34:15 those are typed Feb 06 16:34:30 for example, http://twiki.org/cgi-bin/view/TWiki/SupplementalDocument Feb 06 16:34:46 bitca - "documentation model" basically refers to 1) where discussions about docs reside and 2) how they are merged into distributed documentation (in svn) Feb 06 16:34:55 each supplemental doc has this format: Feb 06 16:34:55 %INCLUDE{SupplementalDocHeader}% Feb 06 16:34:55 %STARTSECTION{"supplementaldoc"}% Feb 06 16:34:55 ...topic content... Feb 06 16:34:55 %ENDSECTION{"supplementaldoc"}% Feb 06 16:34:55 %INCLUDE{SupplementalDocComments}% Feb 06 16:34:57 %COMMENT% Feb 06 16:35:11 Which presumably should be a template Feb 06 16:35:38 yes, but there is a dependency with svn Feb 06 16:35:46 ? Feb 06 16:35:53 So http://twiki.org/cgi-bin/view/TWiki/TWikiAdminCookBook has 2 types Feb 06 16:36:17 Ack Feb 06 16:36:18 ok, each distribution document in the twiki web on twiki.org has an equivalent in svn DEVELOP Feb 06 16:36:30 There is a contradiction in how things work. TWiki is a wiki. But still you need to have checkin rights to SVN to correct a spelling mistake in the TWiki docs. Feb 06 16:36:45 Lavr, only because we have not solved it Feb 06 16:36:52 arthur: two types if needed, yes. for example historical _and_ supplemental Feb 06 16:36:54 * bitca sighs Feb 06 16:37:08 if TWiki04 web on twiki.org was a checkout from svn Feb 06 16:37:16 and we finish the svnstore Feb 06 16:37:28 on to documentation model: Feb 06 16:37:36 then we have the solution to everyones needs right? Feb 06 16:37:49 right Feb 06 16:37:55 Yep. Feb 06 16:37:56 each distribution document on twiki.org has this format: Feb 06 16:37:57 %INCLUDE{DistributionDocHeader}% Feb 06 16:37:57 %STARTSECTION{"distributiondoc"}% Feb 06 16:37:57 ...topic content... Feb 06 16:37:57 %ENDSECTION{"distributiondoc"}% Feb 06 16:37:57 %INCLUDE{DistributionDocComments}% Feb 06 16:37:59 ...existing comments... Feb 06 16:38:01 %COMMENT% Feb 06 16:38:13 the start/endsection determines the official content Feb 06 16:38:23 and all this messy stuff peter is talking about here Feb 06 16:38:27 would not be needed Feb 06 16:38:34 we need to sync the content between thosw tags wit hsvn Feb 06 16:38:44 if TWiki04 web on twiki.org was a checkout from svn Feb 06 16:38:47 and we finish the svnstore Feb 06 16:39:15 official content = static content = webmasters syndrome Feb 06 16:39:18 the goal of this approach is to give the wiki back to the doc folks Feb 06 16:39:27 Sven - I'm not so sure sure you model is complete. Feb 06 16:39:29 * bitca is a doc folk Feb 06 16:39:33 and to solicit doc contributions from casual users Feb 06 16:39:39 as it was in cairo Feb 06 16:39:49 y, svnstore would allow that Feb 06 16:40:11 It's fine for changing typos but how does it deal with things that require some discussion before making the change in docs. Feb 06 16:40:12 Lynnwood, i expect there are small solveable holes - do you see a big one? Feb 06 16:40:14 So I should make changes in twiki.org/.../TWiki/ ? Feb 06 16:40:17 the goal is also to be able to dicsuss documentation Feb 06 16:40:30 oh, you want more than one place to discuss? Feb 06 16:40:48 one discussion per topic Feb 06 16:40:56 as it is now on twiki.org Feb 06 16:41:03 no - but not to commit the discussion. Feb 06 16:41:18 correct, not to commit the discussions Feb 06 16:41:22 yes, but you should also realise that if its not in codev Feb 06 16:41:27 many people will not even see it Feb 06 16:41:39 Twisty (TWisty?) would go a long way to helping the eyes-glazing-over problem Feb 06 16:41:49 * SvenDowideit_ is a strong believer in one discussion web only Feb 06 16:41:52 sven: the twiki web _was_ always the official location for the docs Feb 06 16:41:56 people know that Feb 06 16:42:14 Just look at Plugins. There is the official PluginTopic which people rarely edit and when they do it is in 99% of cases an enhancement. And the dev topic where people discuss. It actually works well today. Feb 06 16:42:16 bye people, must see some blankets Feb 06 16:42:19 yes, bug fewer read the web changes for that web Feb 06 16:42:21 and every twiki 4.0 TWiki web topic has a pointer to its equivalent on twiki.org Feb 06 16:42:23 * ArthurClemens (n=arthurcl@aclemens.xs4all.nl) has left #twiki_edinburgh ("Leaving") Feb 06 16:42:24 see you ArthurClemens Feb 06 16:42:49 so, the open question is: Feb 06 16:42:57 yes, and personally i think its a broken way to do it Feb 06 16:43:01 and always has been Feb 06 16:43:01 Isn't it discuss on TWiki web the topics included from TWiki04 web which are taken and put from/in SVN with Svens svnstore? Feb 06 16:43:42 1. do we want to declare twiki.org as the doc master, do a one way sync into svn, and lock down doc updates in svn Feb 06 16:43:44 or Feb 06 16:43:56 2. do a two way sync, allowing people to work on both sides Feb 06 16:44:09 one major reason we have more docs Feb 06 16:44:18 Um, isn't this a wiki? (i.e. I vote for 1) Feb 06 16:44:26 is that developers were able to commit the doc changes as they made the code changes Feb 06 16:45:05 the current model only supports developers, the reson we need to fix that Feb 06 16:45:15 this is quite different from the discussion point you made earlier Feb 06 16:45:17 s/reson/reason/ Feb 06 16:45:29 yes, and my vote is: SVNSTORE Feb 06 16:45:37 not to mention it's a pita Feb 06 16:45:38 I, as a writer (of English), would like to know how I can help with documentation Feb 06 16:45:39 yes! Feb 06 16:45:48 thus the twiki.org docco updates are the svn updates Feb 06 16:45:53 svnstore would solve this Feb 06 16:46:06 i don't really care where you discuss it (i'd prefer in codev so i see it) Feb 06 16:46:06 * bitca doesn't have a clue what svnstore mean Feb 06 16:46:20 could the TWiki web on twiki.org be made a checkout from SVN and then get it to commit whenever a topic changes? Feb 06 16:46:25 svnstore means that the backend of the web is the svn version Feb 06 16:46:32 thats svnstore Feb 06 16:46:53 so you can use normal twiki interface and change is stored to svn Feb 06 16:46:57 twiki has rcs store only right now Feb 06 16:47:12 sven: i do not want to loose the history of existing topics in twiki web Feb 06 16:47:17 on twiki.org Feb 06 16:47:25 I don't care about back end. I want to be able to edit in TWiki/ and not have that go away Feb 06 16:47:42 bitca - me too! Feb 06 16:47:48 the all important to me is that i build from svn, thus svn is the master Feb 06 16:48:06 if the TWiki web is not linked to twiki.org Feb 06 16:48:10 some glue programming is needed Feb 06 16:48:12 then someone has to manually merge Feb 06 16:48:23 so svnstore == glue Feb 06 16:48:26 sven: no, i want to avoid manual merge Feb 06 16:48:43 lynnwood and i spend probably a few hundered hours on that Feb 06 16:48:55 so have cdot and i Feb 06 16:48:56 and it is still not good merge Feb 06 16:49:01 correct Feb 06 16:49:19 it sounds like this discussion really needs to be taken into the specs for svnstore... Feb 06 16:49:34 specs for svnstore are simple Feb 06 16:49:50 what we need is a plugin on twiki.org that pushes %STARTSECTION{"distributiondoc"}% ...topic content... %ENDSECTION{"distributiondoc"}% back to svn on topic save Feb 06 16:49:52 its just an svn based version of the current rsc store Feb 06 16:50:00 ah Feb 06 16:50:23 ok, i think that is wrong, but i want to make clear - this is my opinion Feb 06 16:50:37 that could be done relatively easily, but would mean a one way sync only, e.g. lock down twiki docs in svn Feb 06 16:50:42 this plugin would also need to svn up Feb 06 16:50:49 no locking down the svn docs Feb 06 16:50:52 a more flexible approch is to do a two way sync Feb 06 16:50:59 otherwise no developer will ever docco Feb 06 16:51:17 so to switch to svnstore we would also need to be able to convert existing 'v history to svndump format. That's a nightmare if you also want the correct dates, interleaving all the revisions of the various topics so the revisions happen in order Feb 06 16:51:24 The front-end documentation model has to be that we can edit the TWiki web and have it become "official" Feb 06 16:51:33 SamHasler, its not a nightmare at all Feb 06 16:51:36 i've done it before Feb 06 16:51:44 That does not necessarily preclude a two-way sync in theory. Feb 06 16:51:45 as ,v formate == cvs format Feb 06 16:52:05 but i do think its a bit pointless Feb 06 16:52:14 ah, didn't know that. Feb 06 16:52:19 pointless why? Feb 06 16:52:20 sven and sam: i do not want to pollute svn with the user comments Feb 06 16:52:39 Can user comments be in an included topic? Feb 06 16:52:39 bitca, we changed away from that in DEVELOP because it caused developers not to docco their changes Feb 06 16:53:01 either we find a place where both can docco, or you will be back to wondering what things do Feb 06 16:53:39 ok, i have to go Feb 06 16:54:01 As I said, it's *necessary* to be able to edit twiki.org/TWiki or we're not a wiki Feb 06 16:54:10 exactly Feb 06 16:54:24 SvenDowideit - I'm not convinced by your point that dev won't do docs if they have to do it through TWiki interface. Feb 06 16:54:26 It may not be sufficient, in which case a solution needs to be found Feb 06 16:54:35 personally i find it _very_ unproductive to work out of svn on docs Feb 06 16:54:59 and I can't believe that developers somehow find it better. Feb 06 16:55:49 bitca: Can user comments be in an included topic? Feb 06 16:55:56 yes, lynnwood, there is little difference for developers to go to twiki.org instead of working on the local copy on docs Feb 06 16:56:02 That potentially solves the svn pollution problem Feb 06 16:56:25 that would be an option, yes Feb 06 16:56:31 PeterThoeny - you currently can't even edit within TWiki locally. Feb 06 16:56:43 i prefer both on the same page for easy scrolling and copy&pasting Feb 06 16:56:58 They are if it's included, yes? Feb 06 16:57:01 Svens svnstore would make it possible to use both TWiki on twiki.org (in TWiki04 web, restricted for developers) and direct text manipulation in svn with their favorite text editor Feb 06 16:57:48 legolas: twiki04 on twiki.org is locked down Feb 06 16:57:56 it is the doc for reference Feb 06 16:58:17 sound like we need to take this dicussion back to TWiki.org for discussion. Feb 06 16:58:21 yes, locked down for ordinary users, but not locked for developers Feb 06 16:58:25 the doc for work in progress release is in the twiki web, marked as DistributionDocument Feb 06 16:58:47 what else can we achieve here and now on this discussion? Feb 06 16:58:52 I also dont see the point of "locking down" Feb 06 16:59:10 is the 2 way sync suggestion that %INCLUDE{DistributionDocHeader}% etc, gets stripped from the topic when it's put in svn? Feb 06 16:59:13 lock down because it is released already, same with twiki03 etc Feb 06 16:59:21 SVN-Store should solve the two ways of editing, that is what it was meant to be or? Feb 06 16:59:34 We're talking on several levels and tangents on this subject. Feb 06 16:59:52 when there are enhancements of documentation it makes no sense of not updating it Feb 06 17:00:16 i have a clear picture how it can be implemented easily with a plugin to sunc one way / lock down svn for doc work Feb 06 17:00:17 From svn is fine if it's a new topic Feb 06 17:00:23 I need to leave momentarily. What can we settle on this topic? Feb 06 17:00:39 i think yes Feb 06 17:00:46 we need to caryy on in codev Feb 06 17:00:48 svn-store is definately a solution for this Feb 06 17:00:53 would the sync strip %INCLUDE{DistributionDocHeader}% etc from the topic when it's put in svn? Feb 06 17:01:16 sam: everything between%STARTSECTION{"distributiondoc"}% ...topic content... %ENDSECTION{"distributiondoc"}% would be synched Feb 06 17:01:26 ideally both ways Feb 06 17:01:39 OK, good folks, I'm signing out at the 3 hour mark. Feb 06 17:02:00 wow, long meeting again Feb 06 17:02:13 Gah. Now I know why I work alone Feb 06 17:02:23 we need to learn to proceed more efficiently Feb 06 17:02:57 <_SvenDowideit> on my way out the door Feb 06 17:03:01 store the exact contents of the topics including the %INCLUDE{DistributionDocHeader}% and the comments in SVN, and only take it out when you build a release. Then you can automate the build by searching for all the DistributionDocHeader topics and everyone knows which topics will be in the release, even when looking at a local copy. Feb 06 17:03:20 <_SvenDowideit> crawford and I definatly prefer to update the docs from our own editors Feb 06 17:03:26 <_SvenDowideit> NO questoin about it Feb 06 17:03:54 <_SvenDowideit> it might be that you need to understand why, but i don't have time to explain it now Feb 06 17:03:59 sven: agreed, give the tools people need, but who is writing most of the docs? Feb 06 17:04:15 <_SvenDowideit> that is probably me and crawford Feb 06 17:04:17 <_SvenDowideit> :) Feb 06 17:04:19 Crawford :-) Feb 06 17:04:31 no comments Feb 06 17:04:42 bye all Feb 06 17:04:44 <_SvenDowideit> though i'm happy to report that many of my edits have been removed over time Feb 06 17:04:53 again, this eithe/or discussion serves NO ONE! Feb 06 17:05:46 If you can make both work, that's ideal. It is necessary to be able to edit using twiki Feb 06 17:06:23 That's pretty simple, yes? Feb 06 17:06:40 I agree bitca. Feb 06 17:07:13 But there are a number of folks who seem to feel that they need to structure specs as evidence of appreciation for their work... Feb 06 17:07:30 maybe an enhanced sectionaleditplugin can help here Feb 06 17:08:02 or some magical syncronisation using unison or similar Feb 06 17:08:03 I like that idea legolas! I commented something along same lines a couple of days back. Feb 06 17:08:14 I'm all for magic Feb 06 17:08:33 thanks bitca :-) Feb 06 17:08:34 they future will show us, bye Feb 06 17:08:42 s/they/the Feb 06 17:08:54 * legolas (n=chatzill@chello084115142036.6.graz.surfer.at) has left #twiki_edinburgh Feb 06 17:09:08 * Lynnwood wonders if peter was going to post notes Feb 06 17:09:13 Sections should be able to be permissioned separately Feb 06 17:09:31 * SamHasler has quit ("(-_-)zzz") Feb 06 17:17:53 Bye all. Missed the end. Was absorbed by two new bugs. Feb 06 17:20:02 'could have used an opinion more (or two) :-) Feb 06 17:20:06 what did you find? Feb 06 17:20:34 Just wrote in #twiki