Session Start: Mon Oct 02 21:56:40 2006 Session Ident: #twiki_edinburgh [21:56] * Now talking in #twiki_edinburgh [21:56] Good evening all [21:57] hi kenneth, will, sam! [21:57] Hi [21:57] * CDot has joined #twiki_edinburgh [21:59] hi crawford [22:00] hey peter [22:01] how is england? [22:02] anybody knows if lynnwood will join? [22:03] will, are you here or are you simply logging? [22:05] rainy [22:05] we had the first rain yesterday since spring [22:05] Flenser: no it ain't! Lovely evening, cold with stars. [22:06] cleared up towards the evening, in time for the bbq :-) [22:06] Rainy here too [22:06] we are not that many people; shall we start or wait some more? [22:06] I only have until 10pm; can we get started [22:07] 50 mins [22:07] ok, i voluneer to facilitating the meeting [22:07] * Lynnwood has joined #twiki_edinburgh [22:07] I am already on the minutes. [22:07] hi lynnwood [22:07] hey [22:08] oh, since lynnwood is here, do you want to facilitate? [22:08] ok, guess i can. [22:08] let me bring up the agenda... [22:08] http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x10x02 [22:08] ta [22:08] Lavr: nice work on WhatsIn04x01 BTW [22:08] * Flenser is currently listening to http://www.archive.org/details/mtw016 [22:08] lets get started then, crawford as 50 min [22:09] * MichaelDaum has joined #twiki_edinburgh [22:09] is wbniv really hear? [22:09] hello everybody [22:09] here [22:09] Thanks CDot [22:09] hi micha [22:09] Hey Will! [22:10] we are abou to start, lynnwood facilitating, kenneth notes taking [22:10] on previous actions; I am finished with Codev topics [22:10] why not just everyone post what they have done on previous actions [22:10] and then see if there are any questions [22:11] and address items no one has commented on. [22:11] Flenser.... ? [22:11] i created RenameTWiki4BranchToMAIN, on agenda item 4 to discuss [22:12] * ArthurClemens has joined #twiki_edinburgh [22:12] I've (only just) added a BugTracking field to ChangeProposal. (Note I dropped an 's', from the suggested BugsTracking as Bug can be plural) [22:13] welcome Arthur - we're just going through "previous action items" [22:13] folks are commenting on their items. [22:13] i just checked, ~develop redirects to ~twiki4. so action item for sven seems to be done [22:13] I wasn't sure we'd reached a decision on the name of the owner field so I haven't added it yet [22:13] hi arthur! [22:13] do you have anything on PreInstallSmartEditAddOn? [22:13] Flenser - what I need is a way to get topics that are old or "would like to have" separated from the committed change proposals that will follow release procedure. [22:14] Larv, that's what the "owner" field is for [22:14] And I need states that fit the process. Right now I am doing it manually on the WhatIsIn field. [22:14] hi [22:15] Larv, what WhatIsIn field? [22:15] sam, the WhatIsIn04x01 is a good example to track the items, e.g. you can model the states after that [22:15] http://twiki.org/cgi-bin/view/Codev/WhatIsIn04x01 [22:15] s/field/topic [22:15] oic [22:16] maybe in the Proposed for field should switch to release names instead of codenames [22:16] Can anyone comment on SvenDowideit's items? Is he even aware actions were assigned to him? [22:17] Flenser - think: "How would one generate the WhatIsIn04x01 topic by a search?" Then I am sure you will get it right. [22:17] On SmartEdit - as far as I can see, it's quite a way from being suitable for prime-time. [22:17] SmartEdit - agree. It is not ready. [22:17] I don't know if new work is going on [22:17] i think we need a report that shows all current proposals for the work in progress release (discussed, accepted, ready for decision), one for deferred (parked, not accepted), one one for done [22:18] Last time I looked at its JS code I got the impression that there's quite some need to clean it up [22:18] because that French developer would work on it in October [22:18] Can anyone comment on RafaelAlvarez' item on TWikiFns? [22:18] I have not seen any progress on TWikiFn topics. [22:18] lynnwood, i commented 5 min ago on svens a.i. [22:19] I think TWikiFns is dead. [22:19] There is no doubt that TWikiFns are parked until someone picks it up. And it will not be ready for 4.1. [22:19] thanks peter [22:20] on reports, we need reports by release number [22:20] "Ready for 4.1" - is there a date? [22:20] Peter, I think that's a good argument for switching the ProposedFor field to release names, not codewords [22:20] yes [22:21] Is there a topic for 4.1 release, or what would be the topic name? [22:21] http://twiki.org/cgi-bin/view/Codev/WhatIsIn04x01 [22:21] right now it is the WhatIsIn04x01 topic, but that name is not that good for a picklist [22:22] We need to take care now. After hotfix and patch was merged - the real releases are major/minor and the patch level is only for "hotfix" type bugfixes. [22:23] So in the picklist we should just have TWikiRelease04x01, TWikiRelease04x02 etc [22:23] yes; patches should be chosen from Bugs web only [22:23] Looking at Codev.TWikiReleases it looks like it would be TWikiRelease04x01x00 [22:23] how about TWikiChanges04x01, TWikiChanges04x02, etc [22:23] no, we need separate topics for work items and released twiki [22:23] what's wrong with WhatIsIn04x01? [22:24] it seems to have worked pretty well for 04x01 [22:24] Bad name for pick list which is what we just discussed. For the SEARCH topic to control release WhatIs is fine [22:24] i think we can take the automation as an opportunity to select good names [22:25] What would "not 4.1 relevant" mean? [22:26] possibly better TWikiFeatures04x01, TWikiFeatures04x02, etc? [22:26] I just can't see it as important. I like being able to see what's happening on a single page, and surely it's up to the release manager of each release how they manage that? [22:26] with 04x01x00 we could ProposeFor point releases too, and those topics are going to be created anyway, we don't need *another* topic for each release [22:26] Arthur: The place I wrote that was Meredith's proposal for a change to a TWikiFn thing. Which is not really relevant when TWikiFn is out. [22:26] actually, singular: TWikiFeature04x01, TWikiFeature04x02, etc [22:27] Some people like automation; some not. [22:27] since you pick it from a picklist [22:27] Can we park this just now, and focus on the release? Please? [22:27] (ok, I will move TopicDisplayName to a separate line) [22:28] or delegate the naming to someone. Flenser or Peter perhaps. [22:28] the name is not critical for current discussion. [22:29] yep, but i like to have all automateed to make it easier and more transparent going forward [22:29] Ok. I also need to know what to call the owner field, should I start a dicsussion in Codev or have we agreed on a name? [22:29] lets take this offline [22:29] ok [22:29] sam, could you create a topic to discuss and finalize the redesign? [22:30] I'll use PostDakarTrackingAndDiscussion [22:30] Do we need further discussion of the TWikiFns? [22:30] Dead. [22:30] RIP [22:30] which is a shame [22:30] ah, yes sam, that is the topic [22:31] any post-mortem needed for now? [22:31] where on the agenda are we now? [22:31] Action added: Sam Hasler: Need more work on ChangeProposal to make a SEARCH possible for WhatIsIn04x01. Discuss further in PostDakarTrackingAndDiscussion. [22:31] ok - i believe review of action items is done. [22:31] on to 2. Review Pending Features of TWiki 4.1 [22:32] comments on WhatIsIn04x01? [22:33] we should pick one by one [22:33] I have put two topics that can may progress with a max 5 min discussion [22:33] Kenneth has done an excellent job in updating it to reflect status [22:33] kenneth suggested two [22:33] I have one additional topic [22:33] yes, very good work by kenneth! [22:33] but Ken goes first [22:33] OrganizeTWikiVariables - we need a short term decision for 4.1. Work can continue on 4.2 naturally [22:34] The discussion topic has many good proposals but we need to focus on 4.1. [22:34] I think it is academic, unless someone is prepared to do the work [22:34] if there is someone doing it, then they need to speak up [22:35] otherwise, we have to rule it out for 4.1 [22:35] simple as that. [22:35] The question at least is if the change already done should be reverted. [22:35] why would we revert it? [22:36] here is what i suggest, taking low handing fruit into consideration: No categorization, remove extra vars that have been documented recently, but keep all rendering shortcuts ones, http://twiki.org/cgi-bin/view/TWiki/TWikiPreferences#Rendering_Shortcuts [22:36] Because some express the oppinion that the change Harald did was not wanted. [22:36] you mean bringing all the TWikipreferences vars into the doc? [22:37] no, remove extra ones from twikirpeferences that apply only to admins [22:37] Harald already added all the VarXXXXX topics from TWikiPreferences. [22:37] and re-add them once we have the categorization [22:37] that's fine, if someone is prepared to do the work [22:37] but that requires a value-judgement [22:37] so it's non-trivial. [22:37] But there is no agreement on which should be removed. Removing files is little work in itself. [22:38] exactly. [22:38] it is trivial: keep only the ones from rendering shortcuts section [22:38] PeterThoeny: could you do that? it only requires editing MANIFEST [22:39] just comment out the ones you don;t want [22:39] why not svn rm them? [22:39] because then you have to svn rm *and* edit MANIFEST [22:39] I'm giving you the easy option ;-) [22:39] If we want to add them in 4.2 in an advanced solution it requires more work to get them back. [22:40] i understand, but isn't it confusing to have extra topics in a svn checkout that are not in the distro? [22:41] i volunteer to clean up the files [22:41] should be easy to recover [22:41] As we say in Danish: "They do not eat bread". [22:41] thanks! [22:41] thanks peter! [22:41] next? [22:41] Lavr - your second item? [22:41] Action item: Peter removes the VarXXXX topics that are admin types. [22:41] plugin handler for content move/rename [22:42] PluginHandlerForContentMove - need owner to drive it. [22:42] that one i really would like to have for tagmeplugin [22:42] not sure why we need it? [22:42] this plugin is used quite a bit by some large companies [22:42] why do we need a handler? [22:42] to notify a plugin that a topic has been renamed [22:43] needed if topic specific data is stored out of band [22:43] you can do that with the existing handlers [22:43] I will document how in that topic [22:43] I think so too [22:43] pretty sure you don't need a new handler [22:44] that is news to me, there are handlers for renaming content, but i am not aware of ngetting notified of a rename [22:44] it's a question of context [22:44] if the save handler is invoked, with the "rename" context set [22:44] you know it;s a rename [22:45] and it is given a different topic name than in initplugin [22:45] right [22:45] hmm, rename context sounds a bit complicated, but if it's doable... [22:45] nah, it's trivial [22:45] Action: Crawford Currie: Propose how to avoid new handler in PluginHandlerForContentMove [22:46] does that work too for attachments? [22:46] before CDot added the new context vars it was complicated comparing topic names; now it is simple [22:46] attachment renames? [22:46] every cgi triggers its own context var [22:46] ok. Now CDot, you had a another item for short discussion? [22:48] yes [22:48] doc fixes [22:48] there are a lot of minor fixes waiting to be done [22:48] Normal and Low priority [22:48] I cannot do them all; i need help [22:48] All in Bug items? [22:48] yes [22:49] there are 37 items against Engine [22:49] of which <10 are really important [22:49] may be that is an indication that it is time to switch back to the wiki way of doc authoring on twiki.org? [22:49] the other area I need help is internationalisation (UTF-8) [22:50] i never understood the reason to manage docs in emacs or vi [22:50] PeterThoeny: no, definitely not. That's a sure recipe for making sure the changes never get done properly. [22:50] and to open a bug item instead of fixing the docs quickly [22:50] this is not the time or place for that discussion [22:50] right now, I need help in closing bug items] [22:51] I'd like request that this discussion not expand into how we manage the docs but stay on the discussion of how to address the doc changes needed. [22:51] some are doc, some are code; most are minor [22:51] i was referring to the doc fixes you mentioned [22:51] as the release is build from svn they have to end up in svn anyway [22:51] ok, lets focus on waht we can do for 4.1 [22:52] how about testing sites, e.g. twiki.org itself [22:53] didn't we have a tag in the bugs web at some point for doc changes? [22:53] merlin.lavrsen.dk is still running current twiki4 svn - updated from SVN every 30 minutes. [22:53] i haven't seen a simple way to see what doc changes are needed. [22:54] I guess we all have to query for open bug items and especially those that are not hard core coder shoud try to resolve those that are doc items. [22:54] it's not just doc [22:55] templates changes as well [22:55] e.g. removing the "Topic Moved" bit from the templates [22:55] these are all changes that don;t need a coder [22:55] it's a question of applying resources to the right places [22:55] That one need coding to implement the current proposal (in history) [22:55] that's not on the list... but [22:56] that was going to be my comment. [22:56] sorry. wrong list. [22:56] Well I ought to do the PatternSkin bugs, and template changes as well [22:56] There is a good proposal for the Topic Moved but it required a Perl hacker. [22:57] requireS [22:57] ArthurClemens: yes, for PatternSkin [22:57] but there are ClassicSkin changes waiting too [22:58] ClassicSkin is not my baby [22:58] basically, everyone can help, even if it's only clarifying a report, reproducing a problem, or attaching a patch [22:58] I see some items have "Documentation" in "Applies to" field, but it's not in filtering option. [22:59] ok, I have to leave you [22:59] no, Documentation is deliberately *not* filtered [22:59] because that erects a screen between "developers" and "documenters" and we really don;t want that [22:59] but filstering by documentation is needed so that non-programmers can help [22:59] as too many developers already donl;t bother with doc [23:00] that sounds like imposing value-judgement over utility... [23:00] you want non-coders to help with docs but make it difficult to find... [23:01] sorry, I can't carry on. I have made my points, I await your conclusions with interest. [23:01] G'night all! [23:01] bye crawford [23:01] * CDot has left #twiki_edinburgh [23:01] g'night [23:01] I think we have the filters we need. We can all help - also with code bugs. Like reproducing those that are cryptic. [23:02] well, i won't press it now, but i would like to request that it be easier to find documentation work that's needed. [23:02] Thomas has added many new one-liners but I have not read them all and I am sure you all have not either. [23:02] just like any other aspect... [23:03] Few bug reports are clean doc only reports I can assure you. [23:03] I read all the reports that come in and it is not my impression that doc updates are frequent. [23:03] sure, but "applied to" can select more than one item. true? [23:04] so if i can see items that need some doc work, i can see where i can help. [23:04] anyway... enough on that. [23:04] but i don't intend to read all the bugs to find where i cna help with docs. [23:04] ok [23:05] We need to talk DATE now. Release date. [23:05] do we want to discuss other items in WhatIsIn04x01? [23:05] ok, let's go on to date for release. [23:05] I have no other WhatIsIn04x01 that are ready for decision. [23:06] I see "PalettablePatternSkin needs owner" [23:06] but that would be me [23:06] Is it complete. I was not sure. [23:07] It is not decided that it is in. Martin proposes it but he does not drive it. And it was not clear from Codev topic that people even agreed. [23:07] it only needs a better interface [23:08] it is an extension to an extension [23:08] It is the same as what you track in another topic with the CSS file defined in a TWiki topic? [23:08] so yes it is in, but PatternSkin is not dependent on it [23:08] but if we include this in core, won't we also need the extension? [23:09] don't include it [23:09] leave it the users to decide [23:09] yes [23:09] it's a nice supplemental doc. [23:09] so thsis one would be documented as a supplemental doc? [23:09] If it is that simple thing then it is a "no-brainer". It is in then. Noone has argued against that. [23:09] peter proposed that, but actually it belongs to PatternSkin documentation [23:10] to work, it requires a little-used Plugin. [23:10] yes [23:10] ok [23:10] Yes. But you can also download the CSS file. Edit it. And upload a new version - right? [23:10] no, because the variables need to be interpreted [23:10] no [23:11] all colors are variable settings now [23:11] and maintained that way [23:11] Oh. I see. [23:11] but for skin users, they will deal with a css file [23:12] it does make skin customization easier. nice work Arthur! [23:12] (it is a neat plugin, but I need to get it to work with PreferencesPlugin) [23:12] ta [23:12] so back to release date? [23:13] I am disappointed noone seems to back TopicDisplayName [23:14] i do! [23:14] we need topic display name and web display name for twiki.org doc work [23:14] I think we all understood the proposal as a change to one of the TWikiFn (former Tags) Tags. at least I did. [23:14] and i just go an email today from a new user that desribed the need for exactly this feature. [23:14] i referred him to it. [23:15] well, the funcional spec is there, just not the technical spec [23:15] I don't know what would be the best way to do it [23:15] Codev/TopicDisplayName - That one I am veru nervous about from a performance point of view. [23:16] yes, we must be sure performance does not suffer [23:16] If all links need to mean a lookup in the target topic to pick up a display name - then performance WILL suffer dramatically. [23:16] Just like LINKTOOLTIPINFO [23:17] but TagMe lookup seems ok [23:17] Because it uses a cache file - doesn't it? [23:17] it uses its own files [23:18] designed for speed [23:18] so it would be like that [23:18] at link render time [23:19] That is a dramatic change to the way we store topics then. [23:19] that is an implementation question [23:19] If I just copy in some new topics from another web at file system levels such a cache is not updated. I am not saying it is impossible. But it is a dramatic change [23:19] it is just meta data about a topic [23:20] shall we take this discussion back off-line? [23:20] to the topic... [23:20] we could create a cach hash that has web.topics storing tooltip info and display name [23:20] Seems like 4.2 material to me if we want 4.1 out soon. [23:20] or create a new proposal for CacheTopicNames [23:20] yes, implementation discussion should go offline [23:20] so back to release date? [23:20] ok [23:20] ok [23:22] shall we set a tentative date [23:22] anyone ready to float a date? [23:22] :-) [23:22] arbitrarily and see if we can do it? [23:22] depends what needs to go in [23:22] Let is calculate a little. The biggest change made is configure. Is it ready? And how long do we need to test it? [23:22] the interface has become worse [23:23] so not prime time [23:23] I found a very basic bug Saturday which meant that many parameters were not loaded correctly. And noone has noticed. So it is not THAT well tested yet. [23:23] ever installed WordPress? [23:24] configure offers more, but should be as simple to use [23:24] or any number of other programs... [23:24] I wonder how many have really tested the plugin installation. From a SVN pseudo-install we tend to have them all already. [23:24] for instance, most users would need to see the advanced options [23:24] i haven't tested it in the svn version of configure. [23:24] not see [23:24] i tried once but did not succeed because of a missing perl module issue [23:25] We probably need some beta releases to enable more to test outside SVN. [23:25] and then I tend to change the interface for a left menu based one [23:25] because the pane contents get longer and longer [23:26] I would like to see a way to re-use patternskin css and images [23:26] we digress from the release date topic... but perhaps it's sign that we really aren't ready to put out a date... [23:27] I think we should target some beta release 2 weeks from now. Not a release candidate but just a beta to get test exposure. [23:27] sounds good. [23:27] ok with others? [23:28] sounds like a plan [23:28] lot of work to do [23:29] k then [23:29] The beta will be made from whatever state and with pending features to go in. But it gives us something to chase. I do not think configure gets properly tested without a beta. [23:29] or two. [23:30] anything else on release date? [23:30] ok [23:30] 4. Rename TWikiRelease04x00 Branch to MAIN [23:31] http://twiki.org/cgi-bin/view/Codev/RenameTWiki4BranchToMAIN [23:31] this is a pending action item from SingleBranchPluginDevelopment [23:31] i think we have agreement to proceed [23:32] but we need owners [23:32] i listed action items [23:32] wondering who can take on what [23:32] The renaming from TWikiRelease04x00 to Main is easy. It is all the follow ups that take a little effort. [23:33] crawford posted: "We don't need to rename the branch. All we do is merge the current TWiki Release04x00 branch to the existing MAIN branch." [23:34] i am a bit confused [23:34] Is it really that simple? [23:34] i do not see a MAIN branch under the branches [23:34] He thinks about trunk I am sure. [23:35] oh, that is another case [23:35] yes, that makes sense [23:35] i think someone good in svn should drive this [23:36] we need a doc to help developers in switching over easily [23:36] (their local check-out) [23:36] we need more than "Local checkouts are up to individuals." [23:37] I think it is a one command exercise. Personally I will not delete mine and checkout a fresh one. I do that all the time. [23:37] That was nonsense. Personally I will delete mine and checkout a fresh one. I do that all the time. [23:38] anyone here volunteering for organzing the change? anyone for writing the doc? [23:38] i will look up the command for changing the svn. [23:38] I think svn switch does it. [23:38] i did that once so i know it can be done and it was a one-liner. [23:39] probably [23:39] ok [23:40] svn help switch [23:40] what about the Bugs? [23:40] Try "svn help switch" on your command line. It is the command. [23:40] thanks lavr [23:41] there was a comment about "Fix Bugs:WebHome installation" [23:41] bugs web fix is up to sven i think [23:41] Bugs web is probably where the real work is. We need either CDot or Sven to evaluate that. [23:41] any comments on that. [23:41] probably sven [23:41] is there some way these request get passed on to him? [23:42] via action items in the release meetings :-) [23:42] i think crawford talks to him frequently [23:42] i do somewhat regularly on irc [23:43] do we have an owner for the rename? [23:43] i'll try to remember to mention. [23:44] i think crawford or sven would be good to own this [23:44] we can't assign, but lets aske them in irc [23:46] Actions added. [23:46] * Sven: We need you to comment on RenameTWiki4BranchToMAIN the effort needed to change Bugs to work with a MAIN branch. [23:46] * Crawford: We propose you volunteer to do the actual rename to MAIN (or copy to MAIN). Will you accept? [23:46] I would like to see the MAIN happen now ASAP. We have talked for so long. Let us get it done. [23:47] yes, before we are in the final steps of 4.1 [23:48] ok, are we done with the meeting? [23:49] I have ONE additional action that I want to beg for [23:49] ok... [23:49] I need help making a script that can do the patch (former hotfix) release. I need the script to make the zip/tgz with only the changed files. [23:51]