Session Start: Mon Oct 16 22:02:45 2006 Session Ident: #twiki_edinburgh [22:02] * Now talking in #twiki_edinburgh [22:02] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x10x16' [22:02] * Set by SvenDowideit on Mon Oct 16 11:13:44 [22:02] hi kenneth [22:03] Hi Peter. Hi all [22:03] Hi Kenneth [22:03] hi sven (offline?) - [22:03] AquaSven is n=sven@203-217-64-29.dyn.iinet.net.au * Sven [22:03] AquaSven on #twiki_edinburgh #twiki [22:03] AquaSven using irc.freenode.net http://freenode.net/ [22:03] AquaSven End of /WHOIS list. - [22:03] hi is everybody? [22:04] I will start the minutes. [22:04] * ktwilight has joined #twiki_edinburgh [22:04] yo :) [22:05] thnak kenneth [22:05] "thanks" [22:05] * mindwarping has joined #twiki_edinburgh [22:05] * ArthurClemens has joined #twiki_edinburgh [22:05] hi [22:06] hi 04ktwilight01 and 04mindwarping01 [22:06] :) [22:06] * SteffenPoulsen has joined #twiki_edinburgh [22:06] greetings (i'm the silent one lurking in the corner ... ) [22:06] introduction round? [22:06] 'evening all (sorry for being late) [22:06] could you state your real name please, for the meeting minutes and so that we can address each other by the first name? [22:06] hi arthur, hi steffen! [22:06] * mindwarping is now known as AndyGraybeal [22:07] thanks andy, and hi andy! [22:07] <-- tis my WikiName :) and my real name (Andy Graybeal) [22:07] hi andy :-) [22:07] KwangErnLiew is my wikiname :) Kwang would be fine [22:07] hi kwang! [22:08] Lavr is KennethLavrsen [22:08] nice to see new participants, welcome! [22:09] * SteffenPoulsen removes the old dust from the channel - look, all new and shiny! [22:09] is lynnwood joining today? [22:09] not sure [22:10] if not i volunteer to moderate [22:10] or, would anyone like to be the moderator? [22:10] - we accept your offer, I think :-) [22:10] Yep [22:10] ok, it is +10 min, shall we start? [22:11] http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x10x16 [22:11] anything to add to the agenda? [22:11] nope [22:11] agenda: [22:11] 1. Review Previous Action Items [22:11] 2. Review Proposed Features of TWiki 4.1 [22:11] 3. TWiki 4.1 Release Timing [22:12] ok, lets start [22:12] ---+ 1. Review Previous Action Items [22:12] - Sam Hasler: Need more work on ChangeProposal to make a SEARCH possible for WhatIsIn04x01. [22:12] sam asked some questions in http://twiki.org/cgi-bin/view/Codev/PostDakarTrackingAndDiscussion [22:13] i think he needs some feedback [22:13] from the community [22:13] i take this as an action item for me to support sam [22:13] I will also need to provide feedback. [22:13] all: please also provide feedback if you have [22:14] me too, I will add to that [22:14] ok, thanks kenneth [22:14] ok, cool [22:14] - Peter Thoeny: removes the VarXXXX topics that are admin types. [22:14] this is done [22:14] - Crawford Currie: Propose how to avoid new handler in PluginHandlerForContentMove [22:14] this is discussion in progress as it seems like even though it was accepted [22:15] - All: Close Bugs items related to docs [22:15] how do we stand on bug fixes? [22:15] I haven't got a full view on that I'm afraid [22:16] I think we soon need to walk through them. Maybe in a bug walkthrough specific meeting. [22:16] i ahve not seen much bug fix activity [22:16] look like not much change from two weeks ago [22:17] Many new bugs that also get closed but old bugs are still hanging. [22:17] yes, we need to work on fixing bugs before and after code freeze [22:17] and really focus on them after code freeze [22:17] I have quite some pattern skin bugs hanging [22:17] I may find some time this week [22:18] I would like to find more time to squash some bugs, but other priorities are in the way currently .. I'll be busy until the 31st [22:18] although not a SMART goal, lets keep this action item open for next time: all to focus on bug fixes [22:19] - beta release [22:19] lets defer that to agenda item 3 [22:19] - MAIN branch switch [22:19] all done [22:19] All done [22:19] - HELP: Need build script extended for patch releases (making the tgz/zip with only changed files) [22:19] what is the status? [22:19] thanks for carrying the switch out so painlessly, very nice [22:20] For the switching to MAIN: Yes, many thanks to CDot, Kenneth and Sven! [22:20] yes, the switch went smoothly, special thanks the kenneth and all involved [22:20] This (script) I really need to aid releasing patch releases. I am still maintaining a manual process for the changed files. [22:21] But I can release 4.0.5 without because it is only 4-5 files that has changed. [22:21] ok [22:21] My greatest concern has been to create a tag with ,v files. [22:21] who would be an ideal candidate taht could help you out? [22:21] I am not sure there is much point in having ,v files in the patch tags on SVN. [22:21] (help for the new script) [22:22] It would be the build scripts that should also create the zip with only changed files. [22:22] the changes are tracked by diff-ing the files and zip 'em up? [22:23] that means crawford would be the most efficient in helping out [22:23] (on the script) [22:23] Yes. But Crawford is efficient on everything and that makes him UNefficient if he always is the one we count on. [22:23] yes; fallback? [22:24] Just to give a 30 second description of the task. [22:24] I am not sure I understand the process of the patches even in pseudo-code, but if the proces can be described somewhere in detail I would like to give it a shot (but alas, only after a few weeks time) [22:24] i was actually thinking of helping out in this, but i ain't sure on how to go about it. if someone is willin' to guide me through, i wouldn't mind spending some time on this [22:24] it sounds trivial, so i thought, why not. [22:24] The task is not just to svn diff all files. It is only the files in the distribution that have changed that should go in the upgrade zip [22:24] but if it's not, i'd bow out [22:25] shouldn't worry too much about putting the ,v files in SVN I think, sounds like the right way to go [22:25] No. I propose that ,v files are only checked in with major and minor tagged releases. And all updates are releative to these for the patch releases. [22:26] well, to know which files have changed is the main concern, i was thinking of checking which files is the most recent, and/or diff-ing each file to see which has changed, then cp && tar [22:26] This way the build script is only modified for each major or minor to build ,v relative to previous. [22:26] lets keep the two items separate: 1. script enhancement to automate patch build, 2. how to handle ,v files [22:26] Sorry for the dumb question: Why do we want to have ,v in the distribution at all? [22:27] to preserve the history of twiki docs at installed sites [22:27] I think it comes down to the basic philosophy of TWiki .. it's just the right thing to do to be aligned with that [22:27] On the script - let me take the action to make a short Codev topic describing the requirement. [22:28] Lavr: Would be very helpful [22:28] kwang: thanks for the offer to help [22:28] please coordinate with kenneth [22:28] That would be helpful. At the moment I don't know how much SVN knowledge would be needed to achieve this (and I am not good with SVN) [22:28] and ask crawford if needed [22:29] thanks Lavr. :) [22:29] Actions: [22:29] * Kenneth to make short description of the requirements for the script to create the zips with only the changed files. [22:29] * Kwang will use the above and make a stab on making the script. [22:29] isn't that enhancing the buildcontrib? [22:29] excellent - gratz on your first action item, Kwang :-) [22:30] :) [22:30] don't expect anything. haha [22:30] That would be the ideal. But even making the script in Perl as a standalone is worth it because it can then easily be added to buildcontrib. [22:30] uh oh [22:30] so it needs to be in perl? [22:31] Right now I will be happy for a script in GW Basic. [22:31] yes it can be done in steps [22:31] ...and every shell script can be fired up with Perl. [22:31] first step a quick solution also to learn what is needed [22:31] * ktwilight will try his best [22:31] ktwilight: you will probably find perl the right solution after having looked at buildcontrib a bit anyway :-) [22:32] ok [22:32] second step to enhance the buildcontrib [22:32] good time for me to learn perl anywayz :) [22:32] :-) [22:32] do you have checkin rights, ktwilight? [22:32] nope [22:33] http://twiki.org/cgi-bin/view/Plugins/ReadmeFirst gets you started [22:33] thanks [22:33] linked from that is http://twiki.org/cgi-bin/view/Plugins/PluginsInSubversion [22:33] start a "would like to check-in" topic [22:34] well, i'll do a stage locally, and take it from there. i know how to go 'bout in svn/svk, so it's really up to using perl [22:34] excellent [22:34] lets continue [22:34] - HELP: Need Bugs:Item2884 closed for patch release 4.0.5. [22:35] :) [22:35] that is done [22:35] Yep. That is why 4.0.5 can be released now. Thanks [22:35] any new required/urgent items for 4.0.5? [22:35] I have not seen any I find that urgent. [22:36] when shall we release 4.0.5? [22:36] (since this is the topic) [22:36] In a few days when I get a long night to do it. [22:36] cool! [22:37] As we just agreed to only put ,v files in SVN tags for minor/major then my only hurdle is gone. [22:37] When I build 4.0.5 ,v files will be relative to 4.0.3! [22:37] sounds great - no real blockers in the way, should be ok to release [22:38] but they are in sync with the topics right? [22:38] Because 4.0.4 was tagged without ,v files. It was a security release with few files changed. [22:38] As I understand it.... [22:38] ok then [22:38] The build contrib during build checkout a tag which is hardcoded in the script. [22:38] And builds ,v files relative to this tagged version. [22:39] ok [22:39] related: i have not measured, but I have a hunch that not many people apply the hotfixes [22:39] most just see the big download box download and are done [22:40] Yes. I have that feeling too. So it will be better with the merged hotfix/patch approach. [22:40] i think it would be better to have the hitfix link also in the big download box [22:40] to indicate that there are two packages to download [22:40] From 4.0.5 this solves itself. Then there are no more hotfixes. [22:40] true [22:41] so no special action needed since 4.0.5 is imminent [22:41] Then all real releases are 4.1, 4.2, 4.3 and 4.1.1 will be first hotfix for 4.1.0. Much clearer. [22:41] Exactly [22:41] time: +40 min [22:41] ---+ 2. Review Proposed Features of TWiki 4.1 [22:42] kenneth, you listed 3 [22:42] any other ones? [22:42] Lavr: Thanks for refactoring the topic [22:43] - FindElsewherePluginAsDefaultPlugin - Start shipping FindElsewherePlugin -- WN [22:43] "We will most likely vote this NO. The votes already given is a 3 against 1 for No." [22:44] Kenneth, Peter and Crawford already voted NO. We assume proposer votes yes. [22:44] any feedback on this by other participants? [22:44] I add to the NO [22:44] Me too [22:45] ok, looks like we have a clear consensus here [22:45] Ping: ArthurClemens [22:45] Any other votes I should register? [22:46] I feel that none of the "add * Plugin" would get a majority. Installing plugins is easy enough, even without CDot's installer. [22:46] I have a bit of a problem with the procedure [22:47] someone puts it on WhatsIn [22:47] then a new topic is created, without a clear proposal [22:47] and then people vote [22:47] so I am not sure what to vote for or against [22:47] There is a clear proposal on this one. Include as default or not. [22:48] but the reasons? [22:48] as described in the procedure, a vote is often not terminal, it can really just mean "proposal should be better" [22:49] yes but WhatsIn04 only says FindElsewherePluginAsDefaultPlugin - Start shipping FindElsewherePlugin -- WillNorris [22:50] the discussion should happen in a specific topic, as it did in FindElsewherePluginAsDefaultPlugin [22:50] will never wrote to FindElsewherePluginAsDefaultPlugin [22:50] Will's proposal was added as a one liner and he never argued further for it on the discussion topic that I created. Noone else has pushed to get this prugin added. [22:50] Would it be a possibility to move on, and you could add your comments on any weak spots in the procedure to the procedure topic so we can discuss them there? [22:50] he has not been seen for a while [22:50] and WhatIsIn04x01 does not provide a linker that a vote is going on [22:51] ok [22:51] ok, lets move on [22:51] - DateFieldPluginAsDefaultPlugin - Start shipping DateFieldPlugin -- WN [22:51] "Consensus reached that it is OK to include function in core. But concern is raised aganst yet another default plugin. Nobody has taken the action to add this to core so we will vote on this one at this release meeting. Kenneth proposes discussing it to: 1. Vote no for the plugin solution. And 2. try and motivate a developer to taking the action." [22:52] Who owns DateFieldPlugin? [22:52] it looks like nobody wants to add this as a plugin [22:52] sorry, JSCalendarContrib [22:52] cdot [22:52] crawford own this plugin [22:53] * mindwarping has joined #twiki_edinburgh [22:53] /nick AndyGraybeal [22:53] ok, it probably needs work before fallback is guaranteed [22:54] i like kenneth's suggestion [22:54] on process [22:54] For the records. Does anyone present want to push for the inclusion of the plugin as it is tonight? [22:54] putting it in the core "the right way" would be preferable, definately [22:54] lets vote on "include as plugin" - 1: yes 2: no [22:55] 2 [22:55] 2 [22:55] 2 [22:55] it is clear that there is work to do [22:55] but that does not invalidate the proposal [22:55] so "include as plugin" for this release, no [22:56] (second vote after that is: "pull code into core" yes/no) [22:56] 4 NO. Noone votes yes. [22:56] any other votes? [22:57] * AndyGraybeal has quit IRC (Read error: 60 (Operation timed out)) [22:57] ArthurClemens: nope, the vote doesn't invalidate it either - just postpones it, pending a better proposal / seeing more work done [22:57] I am veeery reluctant to add any more Javascript to the core [22:57] put in core: yes [22:57] what should be put in the core, exactly? [22:58] harald: if done conditionally it does not add more load [22:58] (I don't see it in the topic) [22:58] I am not concerned about load, I am concerned about third party software in general which is bundled with TWiki [22:58] ok, before we go to second vote, what work needs to be done to add code to core? [22:58] (so I also cannot figure out what would be the benefits) [22:58] No the exact implementation needs to be defined. And we need probably TWO drivers. On the perl side and on the JS side. [22:59] I cannot vote on this, I need more info [22:59] Agree. The proposal on the topic needs to be defined so we know what we mean with adding to core. [22:59] what would be the difference in including the plugin by default? [22:59] ok, too early to vote [23:00] Avoid plugin overhead and better docs for what seen from the customer is just a small extension to existing core function., [23:00] i'd like to get a sense on voices for / aginst adding to core, assuming fallback and other issues are resolved [23:01] do we need better date handlers? [23:01] if majority is against there is no sense in spending more cycles on it [23:01] as I see it, the wish is to include "something" that will support a datefield, adding a meaningful |date| in the form definition. Calendar popup is really secondary (to me, anyway :-)) [23:01] I am for a better date field feature in core. People in general have problems with getting date formats right in forms. [23:01] is there like a list of plugins that are most used by installers? maybe from that we can gauge on what should be added to the core? and/or its needs and reasons why its included [23:02] personally i think date picker in twiki form is a given and should be in core, provided that there is a graceful fallback, and there is no additional load [23:02] but the date picker is javascript [23:02] how to put that in the core? [23:02] it would need to be a server-side check instead, probably, rejecting saving the form if the date field contains something that is not a date [23:03] well, let's not discuss implementation - I would just like the | date | form field supported in the core - some way or another [23:03] the date picker is javascript, if javascript turned off/not available, it should be just a simple text field [23:04] it currently is 3rd party, not sure how it handles js turned off [23:05] ok, i think we got consensus to: [23:05] 1. not add the plugin to the package [23:05] 2. in general positive to idea to add code to core, provided the spec is clear, there is a graceful fallback, and there is no additional load [23:05] +1 from me for that [23:05] agreed [23:06] I have added this to the WhatIs.. topic status. Discussion continues in Codev.DateFieldPluginAsDefaultPlugin [23:06] yes harald? [23:06] Sorry - I just wanted to vote for your proposal [23:06] just checked: no fallback is provided by the plugin [23:07] ArthurClemens: but the text field is still there / gets submitted? [23:07] anyone interested in driving the spec & feature? [23:07] So there is work to be done then. We need an owner to drive the perl part and probably one to drive the JS part. If no owner it ends in PARKED mode. [23:08] Steffen: in the edit page,clicking on the button leads me to the view page without saving any changes. Couldn't be worse [23:08] kenneth that is the right approach [23:09] ArthurClemens: oijs, a bit of work needed then ..something to make you warm on a winters day [23:09] parked it is? [23:09] yes, unless we have someone stepping forward to drive it [23:10] +70 min [23:10] - # NeedSpecForFormValueInitialization - Need to clarify the spec -- TW [23:10] "Autoaccept deadline 16 Oct 2006. Let discuss it, not sure it needs developer attention to implement anything." [23:10] i am not sure if this needs to be discussed [23:11] probably a nobrainer, something that needs to be documented [23:11] Deadline is today. If we do nothing it is accepted. But it is not clear to be if Thomas will implement anything. [23:11] iny input in this? [23:11] "any" [23:12] nope .. can't remember I had any surprises in this area, whitespace on both ends are ignored I think [23:12] I can examine [23:13] ok, can we take this as an action item for you steffen? [23:13] Thomas has a patch ready in a bug item [23:13] yep, ai for me [23:13] * mindwarping is now known as AndyGraybeal [23:13] Bugs/Item2905 [23:13] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2905 [23:14] A very "busy" bugs item. Too busy I would say. [23:15] i am lacking the big picture on the proposal [23:15] something could be buried inside also, needs more digging and examples [23:16] if a code change to make it more forgiving (e.g. with whitespace) i am all for it [23:16] Maybe the best is for TW to implement the small change so we can test it for implications. [23:16] The whitespace is another item. [23:16] if a code change that changes the behaviour we need to look more carefully since it could break existing apps [23:17] I think the problem is that TW seens something changed since Cairo. He proposes it changed back. And we all have difficulty seeing what CAN break. [23:17] if it is just a clarification and doc question it is a nobrainer [23:18] ok, steffen is looking at it [23:18] http://twiki.org/cgi-bin/view/Codev/NeedSpecForFormValueInitialization is what best describes the issue. The bug item is confusing now. [23:19] So the decision is: Steffen to look at it and unless it breaks something we accept it? [23:19] yes - unless we _discover in time_ it breaks something :-) [23:19] Fine with me, but this doesn't matter since I never had problems with form initialisation [23:19] yes [23:20] - CustomizableNewWikiWordLink - nice enhancement, no brainer -- MD [23:20] "No open concerns. Auto accept deadline 19 Oct 2006 KJL" [23:20] "Decision at release meeting is to let Steffen review the proposed change for implications to TWiki Apps. And if he finds it safe it is accepted." [23:20] me neither - this might be key key to allowing for TWikiVars in EditTable and such, though .. let's see what comes of it [23:21] any comments on CustomizableNewWikiWordLink? [23:21] good suggestion on links. I agree keeping link default as it is currently is preferable [23:22] CustomizableNewWikiWordLink. I proposed discussing it to give go ahead to Sven to check it in. The proposed change seems to suit everyone. [23:22] Ping: ArthurClemens [23:22] here [23:22] any last comments before vote? [23:23] customizable link feature: 1 - yes, 2 - no [23:23] it can go in, but I vote for keeping the current layout as default [23:23] What I just said was for another one. But same oppinion :-) [23:23] 1 [23:23] 1 [23:24] 1 with current layout [23:24] 1 [23:24] 1 with current link format [23:24] 1 with current layout [23:24] wow, i wish we had consensus like this most of times :-) [23:25] haha :) [23:25] - PreventLinkToOneself, using 2 new CSS classes -- SvenDowideit [23:25] "No open concerns. Auto accept deadline 22 Oct 2006 KJL" [23:25] (that is the last open one) [23:26] +85 min [23:26] Here is where I meant: I proposed discussing it to give go ahead to Sven to check it in. The proposed change seems to suit everyone. [23:27] i think a detail needs to be checked: [23:27] autolinking of included topics [23:28] if FooBar is included in AnotherTopic FooBar should be linked since it is seen from AnotherTopic [23:28] if looking at FooBar itself it should not autolink [23:28] i will add that note to the topic [23:29] Will you add that question to Codev/PreventLinkToOneself so Sven can answer. He has a patch but it is not there so only he can tell. [23:29] I type too slow. [23:29] I am under the impression that this is very late in the rendering process, meaning origins of topic text is forgotten .. but it might of course be relevant, good concern [23:29] :-) [23:30] The concern Peter has was my major concern also. [23:30] question also if this should be enahbled by default, and if there should be a switch to tunr this feature on and off [23:30] any other feeback on this item? [23:31] Turning it on/off is a matter of CSS, so I don't think it needs another switch [23:31] It will break many of our TWiki apps if it was on by default and it also disabled linking when included. [23:31] Lavr: Yes, of course: Links must be active when included. [23:32] +90 min [23:32] ---+ 3. TWiki 4.1 Release Timing [23:33] I wonder whether there is much testing activity regarding the core changes in 4.1 [23:33] action item: "Beta release week-end of 14-15 October Kenneth builds a 4.1-beta1 and release it for testing." [23:33] it might be good to upgrade twiki.org with 4.1 beta [23:34] I did not have enough time this weekend. But I have started preparing. I have built ZIPS before. [23:34] I would really appreciate that, having t.o. using the beta also [23:34] any numbers on latest performance of MAIN? [23:35] ok, this is an a.i. for me: install 4.1 beta once available [23:35] Yes. We need live installations to run betas. But what THIS beta most of all should be test for is if the new configure works on non-SVN-pseudo-installs. [23:35] The open questions.. (2) [23:35] The new configure does look horrible [23:35] 1. Does the configure work when you install from scratch? [23:36] 2. Does the new extension installer actually work? [23:36] I'd add to 1): How does configure behave in case of missing modules/wrong environment? [23:36] This is almost impossible to test with the current unit framework [23:37] short note on performance: I am currently creating a new site for work, using QuickMenuSkin - I noticed it was about twice as fast as PatternSkin (this was with speedy, 800ms->400ms w. full internationalization) [23:37] the extension installer is excellent, but only works with extensions that have a tgz build [23:37] i had a missing perl module (for gzip i think), so there are additional dependencies [23:38] ok, back to release timing [23:38] so typically, "old" (non-SVN) plugins/addons are not installable even though they are listed [23:39] Steffen: it probably does not have a left bar [23:39] THAT is the kind of issues I would like reported because they will cause problems for the normal admins. [23:39] timings: [23:39] 1. beta [23:39] 2. code freeze [23:39] 3. rc1 [23:39] 4. tentative production release date [23:40] Beta - latest next weekend. I will make it without too much fuzz on release notes etc etc. [23:40] cool [23:40] how much time should we allocate after beta before freezing code? [23:41] We should declare a feature freeze TOMORROW. So tomorrow is last chance to add more to WhatIsIn. Anything after goes in 4.2. [23:41] ArthurClemens: yes, fewer %INCLUDE%/%SEARCH%'s is the main reason, but we should start to performance test now, seeing if we are at par with earlier releases still [23:41] Lavr: I will make a bug item on it [23:41] Beta? [23:42] kenneth, i think it is better to make code freeze after beta, not before [23:42] Can we agree on feature freeze which is not the same as code freeze? [23:42] i see code freeze an indication for rc1 [23:43] People will need some time to implement what is already on WhatIsIn... so we should not add more now. [23:43] let's build and try the beta first, then decide on timings when we have a clue on what issues are in it? [23:44] * ktwilight nods [23:44] other than nobrainers can't be added anyway due to two week period [23:44] i suggest to build beta and freeze at that time or may be a week after that [23:45] and tentative rc1 date two weeks after beta, assuming no major issues [23:45] OK. [23:46] I think that is alright for stating intentions [23:46] +105 min [23:46] i think we are done with the agenda [23:47] anything to add? [23:47] nope, I think we had good progress tonight going through the agenda, happy with that [23:48] s/progress/pace [23:48] And I think the release process works well. Things are well discussed before voting in general. And things not ready are not brought for voting. [23:48] nice :) [23:49] ok, thanks everybody [23:49] good meeting today! [23:50] Thanks good night. Minutes are ready except uploading log. I do that now. [23:50] thanks kenneth! [23:50] you too - I'm off for tonight as well .. see you all around :-) [23:50] (no i need to find someone to massage my neck, i have a stiff neck for two days...) [23:51] thanks all [23:51] good night from Rotterdam [23:51]