Session Start: Mon Mar 12 21:30:13 2007 Session Ident: #twiki_release [21:30] * Now talking in #twiki_release [21:30] * Topic is 'http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x03x12' [21:30] * Set by sven_ on Sun Mar 11 20:17:56 [21:30] I am picking up SWMBO from a dinner. I am probably not back until 30 minutes into the meeting [22:02] * ArthurClemens has joined #twiki_release [22:09] * PeterThoeny has joined #twiki_release [22:09] all: my apologies to be late, i hate to be late [22:10] just back, speeding on highway [22:10] hi Peter [22:10] hi arthur, kenneth, sven! [22:10] Kenneth will be an half hout late [22:10] hour [22:10] sven in switz? [22:11] apparently not in any state [22:12] suspended state ? [22:13] done some interesting things lately? [22:13] wondering if some folks got confused with summer savings time [22:13] i find the voice wiki stuff is quite interesting [22:13] is the idea to speak in text? [22:14] yes [22:14] two scenarios [22:14] you are looking at a project page in twiki [22:14] press the record voiuce mail button to leave a voice mail for this project [22:15] it gets attached [22:15] second scenario: you are on the road or construction site [22:15] call a number, enter pin, enter poject number, and leave a voice mail [22:16] kind of PIM [22:16] third scenario: you fill out a form on a wiki page, with phone number [22:16] on submit, the computer is calling that number and reads the message [22:16] s/pim/gim/ [22:17] group information manager [22:17] interesting [22:17] indexibility will be a problem [22:17] that is the current implementation [22:17] more interesting/useful stuff can be done [22:17] you have it working? [22:17] the 3 scenarios, yes [22:18] also demoed at o'reilly tel conf [22:18] next logical step would be something like mail-into-twiki, but with voice [22:19] e.g. a voice-to-text converter [22:19] btw, shall we wait for kenneth and start then? [22:20] fine with me. Just ping me when we are ready [22:21] with only kenneth, you and me, [22:21] Arrived [22:21] ok to do meeting? [22:21] hi kenneth! [22:21] I will be interviewed by http://hillandknowlton.com/ for a masterclass [22:21] “Masterclass Nieuwe Media & Interne Communicatie” [22:21] maser class new media and internal communication [22:22] about the use of TWiki in our company [22:22] oh [22:22] monthly magazine? [22:22] about the influence it has on internal communication [22:23] it is a master class (1 day conference) for communication professionals [22:23] they will use my material [22:23] in fact they are a bit early [22:23] cool! [22:24] as we are just rolling out TWiki full scale [22:24] i can send you my material if you wish [22:24] please [22:24] this Friday we will officially present TWiki at our company as the new intranet [22:24] ok, i will send you the 3 hour tutorial i give to companies [22:24] great [22:25] tutorial for wiki champions [22:25] that will be me then [22:25] some of that material you could use for the class [22:25] yes [22:26] kenneth, arthur, only three of us seems like [22:26] yes [22:26] can we start, or postpone? [22:26] Yes very few. [22:26] i prefer at least 5 [22:27] since we want to make decisions on features [22:27] DO we have any urgent feature requests where people need feedback? [22:27] dunno [22:27] how about making this an informal meeting? [22:27] I did not have time to check either. [22:28] Yes. Lets just do it informally. We can still give feedback if someone is begging for it [22:28] http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x03x12 [22:28] kenneth, as release mgr, what would you like to discuss? [22:29] I raised a principal questions sort of off topic on Codev/MoreAttractiveForm [22:29] http://twiki.org/cgi-bin/view/Codev/MoreAttractiveForm [22:30] If/when we have default plugins in Patch and Main branch that are out of sync, which one do we post on twiki.org? [22:30] It could soon become relevant for EditTablePlugin [22:31] they shouldn't be released [22:31] only developed in svn [22:31] unless they work on the latest release [22:32] i'd say, experimental code changes only in main for plugins [22:32] So for example - if you implement the MoreAttractiveForm in Main - it should still be the "old" Patch branch version on twiki.org? [22:32] once stable, merge to patch branch and publish on t.o. [22:33] pattern skin will not be published until a new TWiki release [22:34] Patch or minor? (4.1.3 or 4.2.0) [22:34] yes, lrage scale changes to form should not go to 4.1 patch branch [22:35] it should run, not break things. Patch release will only contain bug fixes, so it should still run [22:35] (the old version) [22:35] We can always put experimental versions of for example a new EditTablePlugin as attachment to the EditTablePluginDev topic. [22:36] yes [22:36] but people won't be able to work with it [22:36] unless they have twiki from svn [22:36] then they won't need a download [22:37] You can always do a perl build.pl release and upload a beta zip to the Dev topic if you want a broader audience to a test version. [22:37] yes [22:38] that is a good way [22:38] There is a new guy that requested checkin rights to develop the EditTablePlugin so that is why the principle decision is important. Where do we document this? [22:38] our release process topic [22:39] http://twiki.org/cgi-bin/view/Codev/TWikiRelease04x01Process [22:39] what do you think? [22:39] I was thinking about one of the developer topics. [22:40] ah, that might be better [22:40] That is where a developer will look for the practical info of how to release. [22:40] the process doc is high level [22:40] somehow I am always lookin in Plugins web when looking info on plugin development [22:41] We have a pretty good release doc on TWiki itself. DO we have similar for Plugins? [22:41] what were talking about applies just to to extensions shipped with the core distro [22:42] It would be good to clearly state in a common place that the following extensions (list) are released from Patch branch. Rest from Main branch. [22:42] entry point: plugins web -> readmefirst [22:42] http://twiki.org/cgi-bin/view/Plugins/ReadmeFirst [22:43] two relevant links there: PluginsInSubversion, DakarDevelopersPleaseNote [22:44] http://twiki.org/cgi-bin/view/TWiki/TWikiPlugins seems to be THE document that gives the full picture [22:44] yes, that has the overview, and how to write and publish [22:45] it should be generic enough [22:45] detailed stuff that changes over time might be better in a twiki.org topic [22:46] ? [22:46] off topic: I still cringe at those TOCs above the topic title [22:46] such as which patch branch to use [22:47] Did you mean Codev topic? You said twiki.org topic [22:47] arthur: yes, looks bad on topic, is done so that the manual that includes other topics does not show a toc for every icluded topic [22:47] i meant a supplemental doc, now shipped with twiki [22:48] s/now/not/ [22:48] Ah. I get it. [22:49] so, in twiki.twikiplugins, link to svn info instead of describing svn how to there [22:50] Yep. I can also see that a good beginning was attempted on http://twiki.org/cgi-bin/view/TWiki.TWikiPluginsSupplement. [22:51] so, looks like we are in shape with some cleanup in that supplemental doc and the topics links in plugins.readmefirst [22:52] Plugins/PluginsInSubversion seems to be the best place to add the info. But we should perhaps cross ref a little more from TWiki.TWikiPluginsSupplement and from Codev WebHome. It took time to find. [22:53] I will take the TODO to describe the use of Main vs Patch branch for plugins in Plugins/PluginsInSubversion [22:53] nice [22:55] * HaraldJoerg has joined #twiki_release [22:55] what else should we discuss? [22:55] hi harald [22:55] Hi Harald. [22:55] A topic which we have not touched much is TOC and there is the Codev/TocFailsForIdenticalHeadingNames [22:56] we have very few people and have thus an informal meeting [22:56] Hi. Sorry - I still tried to connect to #twiki_edinburgh [22:56] http://twiki.org/cgi-bin/view/Codev/TocFailsForIdenticalHeadingNames [22:56] Hehehe. That would qualify as a bug under normal circumstances [22:57] I haven't looked at it yet, though [22:57] it's a no brainer that it needs to be fixed [22:57] question is compatibility [22:57] One principle problem to address is HOW to fix this. An obvious fix is to just add a counter suffixed. The BIG question is - do we - and if we do - how do we - maintain compatibility [22:57] ? [22:57] people send out links based on toc [22:57] Compatibility to *what* [22:58] just add a counter at the next duplicate [22:58] If you send broken links based on broken TOC, what do you get? [22:58] People abuse the autogenerated TOC anchors. [22:58] if the old link was like #Description, and the new link would be #Description_25 [22:58] it would break links [22:59] We must note in the docs that it is a really, really bad idea to rely on autogenerated labels [22:59] no [22:59] the first link will still be #Description [22:59] PeterThoeny: If the new link would be #Description_25, then the old has been broken anyway [22:59] But if - as Arthur suggests - we append the numbers only on duplicate then we do not break any compatibility. [22:59] Yes, of course. [22:59] the second header Description will be linked as #Description_2 [22:59] yes, that was the point i was going to make [22:59] What's the problem? [23:00] none [23:00] OK [23:00] I don't know how expensive it is in Perl to keep track of the processed header names and check for duplicates each next header [23:00] keep it compatible for non-duplicates, autnomber for duplicates, starting from second one [23:00] Yep [23:00] So it seems we quickly agree that appending a counter on 2nd, 3rd etc duplicate is the spec to follow. [23:00] yes, that is how i would do it [23:01] this is not so expensive at run time [23:01] simply feed a hash [23:01] a yes [23:01] key is heading name, value is number of occurence [23:02] I will copy paste this fraction of the meeting to the topic for reference. [23:03] Key is heading key, isn't it? [23:03] Sometimes different headings will collapse to the same key due to normalisation of the href attribute [23:04] key could be heading name or anchor name [23:04] there have been discussions to move out TOC as plugin [23:04] * RickMach has joined #twiki_release [23:04] Welcome Rick [23:04] ArthurClemens: For what benefit? [23:04] Hello [23:05] yes, unique anchor name is probably better as key [23:05] anyway, we do not need to discuss implementation details here [23:05] hi rick! [23:05] to make customization easier, and reading from TWiki.pm "as a tag handler that also semi-renders the topic to extract the [23:05] # headings, this handler would be much better as a preRenderingHandler in [23:05] # a plugin (where head, script and verbatim sections are already protected)" [23:06] rick: our release meetings usually have a format, going through the agenda, http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x03x12 [23:06] this time it is an informal discussion since we are only a few folks [23:06] looks like there is code doublure in there [23:07] thanks, just thought I would listen to one, don't really expect to parcipate [23:07] i think it would be challenging to move toc to a plugin without breaking things [23:07] toc is now done last in the var expansion chain [23:07] I do not see the point. TOC is very much used so people would always have it installed anyway. [23:08] so that toc can be built properly also when other vars introduce new text with headings [23:08] myself I would like to create a customized TOC after a topic link, to show what the topic is about [23:08] Lavr: Well, one point would be to optionally exchange TOC with a different implementation [23:08] Only that I don't expect any working alternative [23:08] in that case I would need to pass parameters the way it is rendered [23:08] formatItem, separator, that stuff [23:09] ArthurClemens: Just override TWiki::_TOC, if you feel so inclined [23:09] yes [23:09] In a plugin? [23:09] one laternative is to introduce one more plugin callback, just for toc [23:09] Sort of a post-postrendering handler :-) [23:10] arthur: you can overload any var in a plugin [23:10] but it might change the execution order, thus give you a different result [23:10] yes, against the developing standards [23:12] "toc is now done last in the var expansion chain" - does that mean there are no plugin callbacks at that time? [23:12] Basically yes [23:13] TOC is last because every plugin would be allowed to add headings in its latest callback [23:13] TOC needs to explicitly work on the HTML generated by the rendering process to add the anchors [23:14] also with twiki internal cars it needs to be last [23:14] So a TOC handler must not, in contrast to almost every other variable handler, spit out TML [23:14] onVarExpansionDone [23:14] for example, and INCLUDE will produce headings [23:15] harald, tml to html conversion is done later, after var expansion [23:15] we could use a parameter that prevents TOC when the topic is included [23:15] so technically it is ok to spit out tml as long as there are no vars [23:15] to create better documentation topics [23:16] ah, the previous mentioned issue of toc before heading [23:16] right [23:16] yes, that could be solved with a new parameter to toc [23:16] if a topic 'know's it is included [23:17] I remember vaguely there was a problem in there [23:18] IF gives a problem as well: %IF{"$ TOPIC='WebHome' then=''}% is not possible [23:19] looking at example, http://twiki.org/cgi-bin/view/TWiki04x01/TWikiPlugins [23:20] the topic starts like this: [23:20] %TOC% [23:20] %STARTINCLUDE% [23:20] ---# TWiki Plugins [23:20] To avoid this I usually have TOC before STARTINCLUDE [23:20] Ah - duplicate ideas :-) [23:21] what we leally want is this: [23:21] %STARTINCLUDE% [23:21] ---# TWiki Plugins [23:21] %TOC{ ...switch to turn this off if included... }% [23:21] and some control to exclude a higher level heading [23:22] so, basically: "give me a toc staryting from level 2, but only if not included [23:22] " [23:22] yes, instead of the ---+!! syntax [23:22] (which is uncomprehensible to my colleages) [23:22] incomp... [23:22] in the use case for the twiki manual, we can't use --+!! syntax since this is needed to build the proper top level toc [23:23] that is the basic reason for the current qurky solution of toc, startinclude, and unescaped level 1 heading [23:24] where do we capture this conv? [23:26] looks like a new feature to start toc from specific level [23:26] I think the problems with INCLUDE and TOC are a different level than the duplicate labels [23:26] yes [23:26] yes, a new req topic [23:27] AddControlOverTocRendering [23:27] sounds good [23:28] should we quickly talk about http://twiki.org/cgi-bin/view/Codev/AddAjaxContribsToDistribution [23:28] i think this is a logical step [23:29] Sorry, I don't think so [23:29] It adds a lot of complexity [23:29] any consideration on performance and req env? [23:29] it would facilitate development [23:29] Really? [23:29] How many TWiki users could really use this features? [23:29] it doesn't add anything to any topic [23:30] unless written so [23:30] And aren't these exactly those users who are able to add a Contrib if they need itß [23:30] i'd love to have ajax capabilities without the need to install extra stuff [23:30] we are talking about the default interface [23:30] for example, the tagmeplugin could be done much more user friendly with an ajax interface [23:31] PeterThoeny: So why not simply say that AjaxContrib is a prerequisite for tagme? [23:31] same goes for CommentPlugin [23:32] i loath landylists of dependencies [23:32] avoid dll hell [23:32] and I wouldn't go that far to make Ajax prerequisite of CommentPlugin [23:32] the reason some extensions are more popular than others is because of that [23:32] it would be nice if it is out of the box [23:33] yes, it _is_ important to keep working on a better interface [23:33] s/landylist/laundry list/ [23:33] It creates a dependency of TWiki from the Javascript libraries [23:33] And we really have more urgent problems on the interface than adding more stuff [23:33] the important question here is: does it fall back gracefully? [23:34] I don't [23:34] I love adding more stuff [23:34] to make things simple and clean [23:34] We haven't finished up much of the stuff that was added in 4.0 properly [23:34] which gives rise to lots of support questions [23:34] i need to sign off in 10 min [23:34] I am mostly concerned with performance and with stability. [23:35] Ajax coding standard needs to be graceful fallback [23:35] what does these have to do with the contribs? [23:36] I am nervous we get problems with different browsers. I am nervous that we need to load more files to view a simple TWiki page. [23:38] the idea is that page elements are faster because the page does not have to be reloaded [23:38] are they included only when needed? [23:39] they are contribs, so they are included when inserted into the header [23:39] The minute the features are used in PatternSkin then they get loaded right? [23:40] say, i want it on XyzPlugin, and only use ajax when %XYZ% is present in a topic [23:40] then we need to package it as plugin [23:40] TWikiAjaxPlugin it would be [23:41] that would be neater [23:41] to hide the necessary file includes from the plugin / skin writer [23:43] ok, i need to sign off [23:43] To me it is not a huge issue what is in the distribution. To me I am more nervous that we overload TWiki with more cool things that slow it down. [23:43] will keep the log rolling [23:43] nice talking to all :-) [23:43] see ya Peter [23:43] See you Peter [23:44] Speed is a thing to be tested. [23:44] I will also punch out pretty early. I guess the conclusion on the Ajax one is to continue discussion on Codev topic and bring it up again. We are not ready to decide and not enough for a fair vote [23:45] You can't rely on intuition [23:45] good to hear the sentiment [23:45] knocking off myself, at 23:43 [23:46] good night! [23:46] OK we end the meeting here then. Good night all. [23:47] Good night [23:47] * HaraldJoerg has left #twiki_release [23:47] * RickMach has left #twiki_release [23:50] For minutes: Present was PeterThoeny, ArthurClemens, KennethLavrsen, SvenDowideit(listener), RickMack, and HaraldJoerg