EdinburghReleaseMeeting2006x05x01 irc log All times GMT [21:14] SamHasler to start with lets review the agenda: [21:14] SamHasler 1. Review Previous Action Items [21:15] SamHasler 2. TWiki 4.0.3 Release Timing [21:15] SamHasler 3. Single Branch Plugin Development [21:15] SamHasler 4. Move non-Dakar items into a separate branch [21:15] SamHasler 5. Tinderbox [21:15] SamHasler does anyone have anything to add? [21:15] Drusilla Just one meta-item [21:15] PeterThoeny minutes at http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x05x01 [21:15] Drusilla Seems to me that if we can't make it through the agenda, we should meet the following week [21:15] Drusilla Otherwise every other week is fine with me [21:16] wbniv Drusilla: that sounds reasonable to me [21:16] SteffenPoulsen ok idea .. let's check for interest at 6. [21:17] SamHasler is everyone happy with that? [21:17] CDot y [21:17] SamHasler any other items? [21:17] * SamHasler tables the agenda item: 1. Review Previous Action Items [21:17] PeterThoeny i'd prefer by-weekly meetings [21:17] PeterThoeny in general [21:18] PeterThoeny weekly if there are pressing things to discuss [21:18] Drusilla I guess I assumed that unaddressed agenda items would be considered pressing [21:19] SteffenPoulsen ok .. 1? [21:19] PeterThoeny ---++ develop.twiki.org server move [21:20] PeterThoeny is the fastserver.net logo up? [21:20] wbniv y [21:20] PeterThoeny not on base url http://develop.twiki.org/ [21:20] * MartinCleaver (n=Martin@CPE0013103874cf-CM00137189cf48.cpe.net.cable.rogers.com) has joined #twiki_edinburgh [21:20] SamHasler I'm seeing it [21:20] PeterThoeny and also not on http://develop.twiki.org/~develop/cgi-bin/view/Bugs/WebHome [21:21] MartinCleaver (sorry, I can't stop, but I thought I'd poke my head around the door) [21:21] PeterThoeny this was promised to the isp [21:21] SteffenPoulsen there is a "powered by ES" logo - there needs to be another logo as well? [21:21] wbniv PeterThoeny: i see it in both places [21:21] PeterThoeny where? [21:21] wbniv on the regular wiki pages, all the way on the bottom in the WebLeftBar [21:21] wbniv on the homepage, at the bottom of the page after the links [21:21] SamHasler of front page, bottom of the white box [21:21] wbniv (it's a really short page, tho) [21:22] SteffenPoulsen Peter: are you still on the old DNS, perhaps? [21:22] wbniv seems unlikely [21:22] Drusilla Don't forget svn updates [21:22] Drusilla They bugger up display on develop [21:22] PeterThoeny oh, greasemonkey must be interfering [21:22] SamHasler the rest of this looks like lots of issues for sven, what can we acomplish this meeting? [21:23] PeterThoeny ok, i see it now after tisabling greasemonkey [21:23] CDot well, we can establish who else might address the issues [21:23] CDot since sven is clearly not able to deliver... [21:23] PeterThoeny address from svn mailing is done [21:23] PeterThoeny but takes up space in the subject [21:24] PeterThoeny i'd perfer an address like: WikiName [21:24] SteffenPoulsen that would be nice, easier to sort etc [21:24] CDot apparently it can't be done [21:24] Lavr I never managed to make that work either on my Motion project SVN. SF is very strict on the from address. I have no idea how it worked on the old develop server [21:25] CDot don;t ask me why, but sven said it can't be done [21:25] PeterThoeny ok [21:25] CDot so unless someone can volunteer a solution, let;s table it and move on. [21:25] wbniv sf have probably continued to lock more things down over time [21:25] PeterThoeny on pwd sync, we currently discuss this in the core team [21:25] wbniv well, i know they have [21:26] SteffenPoulsen Lavr: The address need not to be changed, just the "human readable" part :-) [21:26] PeterThoeny i think sf is ok with a human readable part in the "from" [21:27] PeterThoeny apparently issue on commit side [21:28] PeterThoeny move on? [21:28] SteffenPoulsen yep [21:28] SamHasler ---++ TWiki 4.0.2 follow up [21:28] * dot--- (n=twiki@thwackety.plus.com) has joined #twiki_edinburgh [21:29] PeterThoeny will? [21:29] SamHasler no [21:29] wbniv i *just* sent out an email [21:29] wbniv here's the relevant bit: [21:29] wbniv after redoing my procedure above, and answering "NO" to rcs questions,
i still get the following differences:

wbniv@brandon:/tmp$ wc -l upgraded-to-402-diff.txt
21 upgraded-to-402-diff.txt
wbniv@brandon:/tmp$ cat upgraded-to-402-diff.txt [21:29] wbniv arg, stupid paste [21:29] wbniv don't these worry other people? did i do the diff wrong or what? i
don't feel comfortable releasing a patch file with these issues
outstanding. [21:29] wbniv also, i'm actually worried about having to answer "No" to rcs
questions, but i don't see any options to patch which would
automatically answer "No" for them. any other options? [21:30] wbniv Only in TWiki-4.0.2/pub/TWiki/PatternSkin: background_action.gif
Only in TWiki-4.0.2/pub/TWiki/PatternSkin: background_button.gif
 [21:30] wbniv , [21:30] wbniv . [21:30] wbniv . [21:30] wbniv Binary files 401upgraded/pub/TWiki/PatternSkin/patternskin_screenshot_full.png
and TWiki-4.0.2/pub/TWiki/PatternSkin/patternskin_screenshot_full.png
differ [21:30] Drusilla erm... [21:30] CDot wbniv: answering "no" is manageable [21:30] CDot as long as people are told in advance [21:30] wbniv errorprone [21:30] PeterThoeny will, no details, just status [21:30] wbniv but i don't know of any other soln [21:31] wbniv searching technical solutions [21:31] wbniv people can reply on twiki-dev, i guess [21:31] PeterThoeny i'd say, do not spend much time on diff if 4.0.3 comes out next week [21:31] wbniv so, not done [21:31] wbniv true, but we're going to have exactly the same issues for the 4.0.3 patch [21:31] wbniv so, let's move on in the meeting [21:31] wbniv and we can work out the technical issues on mail/twiki.org [21:31] wbniv ok? [21:32] SteffenPoulsen ok [21:32] PeterThoeny ok [21:32] SamHasler ---++ TWiki 4.0.3 [21:32] PeterThoeny i will do the twiki.org doc part [21:32] SamHasler Add the 6-8 urgent/requirement bugs (Action - all) [21:33] wbniv we should review if any outstanding items are required for 4.0.3, right? [21:33] PeterThoeny quick review ok [21:34] CDot well, it would be OK if d.t.o was responding [21:34] * Lavr keeps quiet because I am not up to date since I came home on current open twiki4 bugs [21:34] Drusilla Why don't we get back to it then [21:35] PeterThoeny waiting..... [21:35] wbniv me2, let's come back to that? [21:35] PeterThoeny well, lets discuss other things and get back to review once server is back [21:36] PeterThoeny will, will you do the build? [21:36] wbniv yes [21:36] PeterThoeny ok [21:36] PeterThoeny cool [21:36] wbniv with your half on twiki.org as you've graciously offered before [21:36] PeterThoeny release date, last time we target 09 may [21:37] Lavr I saw some SVN commits to TWiki4 branch where cosmetics were changed on TWikiPreferences and other similar topics. [21:37] PeterThoeny and? [21:37] Lavr I would like people to reevaluate if these are necessary for a 4.0.3 release because these topics are the ones that are a PITA for upgraders [21:38] PeterThoeny good point [21:38] Drusilla They'll have to be addressed at some point. But it doesn't have to be now [21:38] CDot the toughest one to deal with will be UserForm/NewUserTemplate [21:39] PeterThoeny did they change in 4.0.3? [21:39] CDot yes [21:39] Lavr If the changes are functional there is a point. But if they are just cosmetics then it makes less sense. [21:39] CDot true [21:39] PeterThoeny what is lost if we revert the change to the user form & template? [21:40] CDot why would we do that? It's a bugfix [21:40] CDot but lavr is right [21:40] CDot it's a functional change [21:40] CDot cosmetics are all we should worry about [21:40] PeterThoeny what is lost if we revert? [21:41] SteffenPoulsen we should avoid getting technical at this meeting, and instead file new Item / Codev topic. Better to have details and for/against there [21:41] CDot PeterThoeny: a formfield attribute (Email -> H) and the E-mail field from NewUserTemplate [21:41] PeterThoeny action item: review changes to pref topics and user form / template to see if/what should be reverted [21:42] PeterThoeny to ease upgrade pain [21:42] Drusilla So it's important [21:42] CDot action for who? [21:42] PeterThoeny yes, for who? [21:42] CDot hold on, we are getting focused in on an incredibly minor detail here [21:42] CDot we need to be more concerned about the buglist [21:43] CDot are we at risk of releasing 4.0.3 with a killer bug in the queue? [21:43] PeterThoeny that's why i suggest to take this offline with an action item [21:43] Lavr At the end of http://twiki.org/cgi-bin/view/TWiki/UgradingTWiki04x00PatchReleases there is a list of files. Not that long. We should all look at the changed to those files and if the changes are just cosmetic then consider reverting them. Or not include the file in the _changes zip [21:43] CDot Lavr: good idea [21:44] CDot of more imortance for this meeting; are there killer bugs inthe queue? [21:44] CDot I see there are several Urgent and Requirement [21:44] CDot but no-one has followed up on last meetings actions, AFAICT [21:44] * PeterThoeny is off for one min [21:46] * PeterThoeny back [21:46] * wbniv wonders why develop.twiki.org is soooooooo slow [21:46] wbniv it's hard to pull up the outstanding bug list [21:46] Drusilla All of us hitting it at once? [21:47] wbniv possibly [21:47] wbniv but it's a real computer now [21:47] wbniv not just part of one... [21:47] SteffenPoulsen it's doing its svn update; svn update does a lot of io wait [21:47] dot--- Please excuse me, I don't want to interrupt the meeting, so please ignore this comment - but when the end of the meeting is reached, I would like to ask a question if I may be so bold. I shall be quiet until then. [21:48] SamHasler ok, well deal with that at the end of the meeting [21:48] SamHasler back to the urgent items [21:48] Drusilla Perhaps move to next item until d.t.o straightens itself out? [21:48] SamHasler ---++ CSS issue discussed. Arthur has done some fixes but we are not sure the problem is fixed. No actions [21:49] SamHasler do we need to talk about that? [21:49] Drusilla As he's not here, I reckon not [21:49] wbniv and it's not fixed [21:49] CDot SteffenPoulsen: I rewrote the svn update; it now only updates the files that have changed :-) [21:49] SamHasler ---++ Moving twiki.org to TWiki 4 [21:50] PeterThoeny sven installd the libs last night [21:50] SteffenPoulsen CDot: great - sounds like I need to check that out [21:50] PeterThoeny i am currently talking with isp on server setup in regards to email [21:50] PeterThoeny problem is that this is not an isp issue [21:50] PeterThoeny it is a solaris config issue [21:51] PeterThoeny the isp is not that familiar with solaris [21:51] PeterThoeny sven is busy with other things [21:51] CDot have we abandoned 4.0.3 then? [21:51] PeterThoeny so it may take a few more days until email is working [21:51] PeterThoeny without email registration does not work [21:51] SamHasler CDot, we'll come back to it [21:51] SteffenPoulsen CDot: getting back to 4.0.3 once d.t.o answers [21:51] Drusilla It's answering me, but without any skin [21:51] SteffenPoulsen PeterThoeny: OK [21:52] PeterThoeny i think we can switch over soon [21:52] PeterThoeny the test install looks good so far [21:52] CDot d.t.o is fine; 'top' is kjournald [21:52] PeterThoeny we can run twiki 4 on TWiki04 web instead of TWiki web until TWiki web is up to date [21:52] Lavr I do not have any skin on d.t.o. either. And it has been like that for 3-4 mins now [21:53] Drusilla Yeah, not just svn issues [21:53] Drusilla But that's for offline [21:53] Lavr It happens very often after the server move [21:53] PeterThoeny question is user topic update [21:53] CDot PeterThoeny: I mailed you on that [21:53] CDot didn't you get my mail? [21:53] PeterThoeny i sent crawford the list of e-mail addresses a while ago [21:53] SteffenPoulsen PeterThoeny: delighted that twiki4 is closing in on twiki.org [21:54] CDot I replied the day after you sent it [21:54] CDot with the script [21:54] PeterThoeny i have not seen the reply then [21:54] CDot bugger; because I deleted it, as you requested [21:55] PeterThoeny well, i got the reply that you got the e-mails [21:55] PeterThoeny but not the updated script [21:55] Drusilla Take it offline? [21:55] SteffenPoulsen darn [21:56] PeterThoeny crawford: did you create a custom script, or did you check the changes in for general use? [21:56] CDot neither [21:56] CDot I worked the list you gave me [21:56] PeterThoeny ok, what is the status then? [21:56] Drusilla Could you guys take it offline, so we can move on? [21:56] CDot Drusilla: yes, will do [21:57] PeterThoeny btw, who is taking the minutes? [21:57] SamHasler is that Moving twiki.org to TWiki 4 covered? [21:57] Drusilla Without mail, it can't be moved, so I guess so., [21:57] SamHasler sorry I meant to ask that at the start [21:57] Lavr (still no skin on d.t.o. Just checked. "The requested URL /~develop/pub/TWiki/PatternSkin/layout.css was not found on this server.") [21:59] PeterThoeny twiki 4 on twiki.org discussion done [21:59] SamHasler ok, skiping item 2. TWiki 4.0.3 Release Timing for the moment [21:59] wbniv Requirement: 6 Urgent: 10 [22:00] SamHasler ---++ 3. Single Branch Plugin Development [22:00] CDot wbniv: thx [22:00] SamHasler first of all [22:00] SamHasler how urgent is it to everyone that we find a solution to this soon? [22:00] wbniv *soon* is important; _today_ is not [22:01] Drusilla I'm happy with the way things are, so not urgent to me [22:01] Lavr At least we should agree if the TWiki4 or DEVELOP is the Plugin master. The current situation is a farce. [22:01] Drusilla TWiki 4 should be the master for anything that runs in Dakar [22:02] PeterThoeny single branch plugin dev model: [22:02] PeterThoeny - No: Crawford, Meredith [22:02] PeterThoeny - Yes: Kenneth, Martin C, Scott Hoge, Peter [22:02] Drusilla And, if possible, a script or some such to copy plugins to develop [22:02] Drusilla When did we vote? [22:03] Lavr Both sides have valid points. We need a 3rd proposal that address the issues. Also known as compromize. [22:03] PeterThoeny and we do not know what all the other plugin developers think' [22:03] wbniv after this weekend's flareup, i haven't had time to comment or analyse; perhaps we should just have more discussion this week on twiki.org [22:03] wbniv and [22:03] wbniv make it the single item for next week's (short?) meeting? [22:03] PeterThoeny no, no compromise [22:03] PeterThoeny i's like to have a playful and open discussion [22:03] PeterThoeny so that we can synergize [22:03] PeterThoeny there is a big difference in compromise and synergize [22:03] SteffenPoulsen problem is how we would like it to be once Edinburgh and next releases are out [22:04] PeterThoeny compromise is 0,5 for each party [22:04] Lavr When you have 2 options that both have problems then you need a 3rd option that addresses the issues better. [22:04] PeterThoeny ynergystic solution is 1.5 for each party [22:04] Lavr That is a matter of language. [22:04] Lavr I use the English words I know. [22:05] SamHasler is everyone happy to have more discussion for a week and have a meeting next week to discuss it? [22:05] PeterThoeny a 3rd option that addresses needs on both side is a synergistic way, yes [22:05] wbniv yes, let's look for that [22:05] Lavr We need a solution that both makes things simple for occational users, promotes stable plugin API and allows experiments. [22:06] PeterThoeny and makes it simple for admins (avoid multiple click here or click there) [22:06] Lavr Yep. All that. [22:07] Lavr And some "plugins" are not really plugins. Example PatternSkin. [22:07] PeterThoeny and all twiki apps [22:07] Lavr And many contribs [22:08] SteffenPoulsen needs more thought .. let's try to commit each other on a playful approach for a week? [22:08] PeterThoeny is it userfriendly to mainatin apps in multiple branches? [22:08] SamHasler Is everyone happy to have more discussion for a week and have a meeting next week to discuss it, Yes or No? [22:08] wbniv Yes [22:08] SteffenPoulsen Yes [22:08] Drusilla yes [22:08] SamHasler peter? [22:09] wbniv bbi5 [22:09] Lavr Yes. And people should put NEW proposals in Codev. Not just continue to argue for one or the other. Because all arguments are valid and good. [22:09] CDot No. I don't think voring on this issue is appropriate. Different users have different expectations, and different requirements. [22:09] PeterThoeny this is an important/not urgent thing that needs to be addressed [22:09] Drusilla I thought we were voting to table it for a week [22:10] PeterThoeny process changes that are forced on the community without agreement are never a good thing [22:10] CDot Drusilla: sorry, you are correct. I am happy to table it. [22:10] CDot Peter, please try not to use emotive language like that [22:10] CDot you will just wind people up [22:10] Drusilla I would, however, urge people not to remove things from the 4.0.x branch if they are meant to work with Dakar [22:11] PeterThoeny therefore the multi-branch plugin introduction needs to be addressed [22:11] SamHasler it will be addressed by a week long discussion on Codev [22:11] PeterThoeny i find it ok o discuss for a week in codev [22:12] SamHasler there is the issue of which branch to store plugins in, in the mean time [22:12] Lavr Right now the view that 99% of developers have is that TWiki4 is THE plugins branch except for those few "plugins" that are Edinburgh. Like all the new small "Tag" plugins that Meredith works on. [22:12] PeterThoeny s/o/to/ [22:12] Drusilla Yes, and I agree with that, Kenneth. [22:12] CDot Lavr: right [22:13] Drusilla As I said above, anything for Dakar belongs in 4.0.x [22:13] Drusilla That seems pretty clear and simple [22:13] Lavr For those arguing single plugin branch remove from DEVELOP instead or plain ignore it. And update ONLY TWiki4. Because that it what hits our customers. DEVELOP is a sandbox. [22:13] SamHasler is everyone happy that using TWiki4 will cause the least disruption for this week? [22:14] Drusilla Makes sense to me. [22:14] PeterThoeny not like that: using twiki4 branch implies agreement with multi-branch dev model [22:14] PeterThoeny using develop branch promotes the single branch dev model [22:14] Lavr No Peter. Not more than using DEVELOP. [22:15] Lavr The CUSTOMER argument is what should matter. Testing for current customers should focus on shipping version = Twiki4. [22:15] * CDot is quite happy to change the names of the branches to TWEEEDLEDUM and TWEEDLEDEE if it helps stop this insane discussion.... [22:15] PeterThoeny if i only develop plugin in develop branch it is a single branch dev, also at a later point when there is a twiki 5 branch, twiki 6 branch etc [22:15] Lavr We are talking short term Peter. Like weeks. [22:16] SteffenPoulsen we need some way to handle the "generic case", no doubt .. I can start off by deleting plugins from DEVELOP to send the signal [22:16] PeterThoeny if i d not make a point the status quo will win [22:16] Lavr If you continue developing on DEVELOP only noone except YOU will test them. [22:16] Drusilla No. Do not delete plugins from DEVELOP [22:16] CDot please do not delete plugins from *anywhere* [22:16] CDot until there has been some resolution of this debate [22:16] Drusilla If anything, we need a script to copy plugins from 4.0.x to develop for ease of installation [22:17] CDot then whatevber the outcome, we can take action [22:17] SteffenPoulsen fair enough .. [22:17] Lavr I am sure the end result is something different than DEVELOP OR TWIki4. And if we are committed we always find ways. [22:18] Drusilla It's important that dakar plugins be tested against whatever we're doing in develop [22:18] CDot right [22:18] PeterThoeny yes [22:19] PeterThoeny i really hope we find a constructive way to discuss things [22:19] Drusilla And as I'm using a bunch of them, having them copied to develop works for both dakar dev and develop testing [22:20] wbniv ok, we've agreed to discuss this more; can we move on please? [22:20] PeterThoeny we are at 80 min now... [22:21] SamHasler develop still appears to be down so... [22:21] SamHasler ---++ 4. Move non-Dakar items into a separate branch [22:21] PeterThoeny that depens on the previous subject [22:21] Drusilla I'm just sick of all that cruft in my installs [22:21] PeterThoeny but let the person explain what the idea is [22:21] Drusilla I can't delete them, because they'll just reappear the next time i do an svn up [22:22] CDot Drusilla: what are you talking about? [22:22] Lavr Define cruft. [22:22] Drusilla Abandoned plugins, skins, etc. [22:22] wbniv Drusilla: you can do selective checkouts of svn [22:22] wbniv of directories [22:22] wbniv it would be more work, but i think it can accomplish what you want [22:22] Drusilla They all go into twikiplugins [22:23] wbniv yes, you can checkout directories *within* twikiplugins, iirc [22:23] * wbniv should review the svn book [22:23] PeterThoeny is the unwanted extension the main point? are there others? [22:23] CDot Drusilla: are you volunteering to work through the plugins and identify those that are orphaned? [22:23] Drusilla But i have to know which ones they are, which doesn't work [22:23] Drusilla I thought there was mail sent out about skins, at the very least. [22:23] Drusilla We're not removing anything from t.o, after all [22:23] Drusilla Just out of svn [22:24] PeterThoeny do you have other reasons besides "cruft" for moving extensions out? [22:24] Drusilla By definition, authors of addons (in the generic sense) that haven't been updated to Dakar aren't working in svn, I think [22:24] SamHasler Drusilla, if you could work on a subset of plugins without the others changing in SVN would that meet your needs? [22:25] Drusilla It also makes logical sense to only have 4.0.x stuff in that branch [22:25] Drusilla Stuff that doesn't work in Dakar doesn't belong there. [22:25] CDot hang on just a mo, let me make sense of this. [22:25] CDot you are advocating removing plugins from SVN that don;t work with TWiki-4? [22:25] Lavr People are working hard (Steffen) in turning cruft into working plugins also in Dakar. [22:26] Drusilla In which case they belong in 4.0.x [22:26] Lavr Who should judge which of them are cruft and which are silver needing some polish? [22:26] CDot Drusilla: live with the cruft. Better, turn cruft into non-cruft. [22:26] Drusilla There are ones whose pages explicitly say "do not use this in 4.0" [22:26] PeterThoeny so it is a single branch vs multiple branch question [22:26] CDot what? [22:27] Drusilla SessionAddOn, or whatever it's called. I've run across a couple of others [22:27] Drusilla I haven't done a thorough inventory. [22:27] SamHasler not nesesarily, you could just delete them, it's easy to restore them and they've already been tagged [22:27] Drusilla But there are ones that are explicitly outmoded [22:27] CDot SessionPlugin, and others, are maintained in SVN because they are released to support Cairo [22:27] CDot there is no good reason to delete them [22:28] PeterThoeny i think this is a how to use svn question [22:28] Drusilla I guess I didn't realize that 4.0.x was being used to build Cairo stuff [22:28] SamHasler (did not mean to imply that he supported the view) [22:28] SteffenPoulsen yep, it's just a single/multi branch question, just the iteration-1 version [22:28] PeterThoeny we should trake this offline [22:28] CDot if you want something to tidy, oh tidy minded one, go tidy up Codev >:-) [22:28] PeterThoeny if someone finds a way to instruct svn to ignore a directory, let us know [22:28] Drusilla Guess you haven't noticed the 20 times I've tried. [22:29] Drusilla But if 4.0.x is being used to update Cairo, then I withdraw the suggestion. [22:29] SamHasler ok, we'll table this for now [22:29] SamHasler ---++ 5. Tinderbox [22:30] SamHasler SteffenPoulsen, this was your idea [22:30] wbniv same as before, every now and then i update the tinderbox scripts (such as they are---like the unit tests, they could always use more improvement) to work with the latest svn [22:30] Lavr When we redesign the SVN layout (the synergy solution) and of this means not having twikiplugins as a subdirectory to any core branch - one can much more easily checkout only selected parts of the plugins branch. Something to consider for the proposals on codev. [22:31] SteffenPoulsen yep, the old box didn't have the horsepower to do svn, just curious if we were in more luck now? [22:31] SteffenPoulsen s/svn/tinderbox [22:31] wbniv to me, it's a matter of can we get another box? [22:31] wbniv SteffenPoulsen: right [22:31] SteffenPoulsen I'll volounteer a box for it if it's just a box that is needed now [22:32] PeterThoeny i can ask fastmetrics if they'd host another box [22:32] PeterThoeny i can also ask a company if they provide+host the box [22:33] SteffenPoulsen that would be perfect .. [22:33] Lavr The extra box should not consume new bandwidth I assume. Only mainpower and space. [22:33] PeterThoeny will, could you specify what you need? [22:33] SteffenPoulsen last time the issue was not the box, but the load it would put on the existing svn service .. just curious if the new svn service could handle the load from it [22:33] CDot sorry to be a damp squib, but who is going to set up / maintain this tinderbox box? [22:34] CDot it's a wonderful idea; I just want to be sure we have the personpower.... [22:34] SteffenPoulsen me! me! me! oh, pick me! [22:34] CDot anyone else? >:-) [22:34] PeterThoeny i like that :-) [22:35] wbniv the requirements would be very light (don't need much hp, memory, BW, etc.) [22:35] Drusilla Most of us are pretty overloaded, so volunteers are good [22:35] wbniv CDot: well, i'd help, since i've already written the scripts [22:35] wbniv but if someone else where to setup the actual box for use, that'd be great! [22:35] CDot SteffenPoulsen: but no humming....!! [22:35] wbniv s/where/were/ [22:35] PeterThoeny so steffen is volunteering the box and manpower [22:35] PeterThoeny question then is where to host [22:36] wbniv tinderbox.twiki.org ? [22:36] wbniv oh, where to put the box itself, i see [22:36] wbniv nm :) [22:36] SteffenPoulsen I was thinking of the twikivms.forskernet.dk server (serves twikivmdebianstable), which doesn't have any cpu load at all (it's not a biggie though, just 2x500mhz) [22:37] CDot sounds like something that can be taken off-line? [22:37] SteffenPoulsen so box + line + manpower + naive optimistic attitude, all ready .. yep, I'll grab a hold of will [22:38] SteffenPoulsen if the svn service is down one day, you all know why :-) [22:38] SamHasler have we resolved this? do we know what can be done by whom? [22:38] CDot y [22:39] wbniv however, it would be nice to get a real company to "foot the bill" at some point, no? [22:39] wbniv instead of personal hw [22:39] CDot good point [22:39] PeterThoeny yes [22:39] SteffenPoulsen wbniv: yep, hope Peter will do a parallel approach on a new box [22:39] PeterThoeny i'll do that [22:39] CDot next agendum? [22:40] SamHasler I think that wraps things up, unless anyone can get develop working [22:40] CDot it *is* working [22:40] PeterThoeny will: please send me an e-mail with what this does and why we need it (so that i can "sell" it to the corp) [22:40] CDot I'm logged in; load is minute [22:40] SamHasler so can we go back to urgent items [22:40] Lavr Still no skin. Server responds but the css files are missing [22:40] SamHasler do we need a skin? [22:41] CDot hmmm [22:41] PeterThoeny not for the review [22:41] PeterThoeny first one i discover: http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2168 [22:42] CDot if you want a skin, use ~twiki4 [22:42] Lavr UTF-8: Form.pm strips characters from field names [22:42] SamHasler http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/WebChanges [22:43] PeterThoeny 2168, is that a requirement? [22:43] CDot I guess it is, for some people [22:43] PeterThoeny affects intnl sites [22:43] Drusilla oooo..skin! [22:43] CDot frankly, I've been avoiding UTF8 issues [22:43] CDot because of my limited knowledge [22:44] PeterThoeny i'd say this item does not hold back 4.0.3 [22:44] SteffenPoulsen not to me, this needs to be tested for sideeffects as well [22:44] CDot ? [22:44] Lavr I agree. It is not a new bug and its fix probably needs a lot of testing [22:44] PeterThoeny yep [22:45] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2158 [22:45] CDot ok. 2158 must be addressed. [22:45] PeterThoeny TWiki leaks memory - mod_perl processes continually grow [22:45] CDot I have been trying to get time all week [22:45] CDot it must be looked at, though [22:46] CDot 2157 is a relatively straightforward fix [22:46] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2151 [22:46] PeterThoeny Delete usecase broken in PatternSkin [22:47] PeterThoeny urgent/new [22:47] Lavr I have had recent user issues with not being able to delete attachments because an attachment with same name had been deleted before [22:48] SteffenPoulsen I renamed it because it appears to not be an issue in classic, haven't looked into it more [22:48] CDot this needs to be verified and fixed if it is a genuine issue [22:48] CDot the one with the attachments is new to me [22:48] Lavr I wondered about that renaming. I think Meredith has a real issue. [22:48] Drusilla Well, I've sure run into it. Obviously. [22:48] CDot yes, but you use Develop [22:49] CDot it must be verified on TWiki4 [22:49] Lavr It is TWO cases that needs testing. Delete topic that has same name as one deleted before. And same case with attachment filename being same [22:50] Drusilla Well, it's pretty obvious in PatternSkin: [22:50] Drusilla %MAKETEXT{"Delete topic..."}% [22:50] PeterThoeny is this a showstopper? can't you specify another name if the name is already there? [22:50] Lavr The case I had was a very long filename (A windows path used as filename by mistake) [22:50] Drusilla It's *very* user unfriendly [22:50] Lavr With attachments you cannot rename when you "delete". [22:51] PeterThoeny oh, yes, true [22:51] Lavr With topics some users find out to rename while deleting. Many give up. [22:51] CDot I think it's probably genuine [22:51] CDot but no-one has reported the attachment rename issue [22:52] Lavr I saw it yesterday and did not have time to open a bug report yet [22:52] CDot surprising; maybe bpeople don;t delete attachments [22:52] Lavr It was while I was in Las Vegas. [22:52] PeterThoeny both are usability issues, but do not warrant a delay of 4.0.3 [22:52] CDot agreed [22:52] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2133 [22:52] PeterThoeny ditform.pattern.tmpl missing some of the save parameters [22:52] PeterThoeny requirement/new [22:54] PeterThoeny any comments? [22:54] Drusilla You can, of course, take any of my requirements out as long as I've worked out a bug fix in develop [22:54] Drusilla These are serious issues with my users [22:55] Drusilla Perhaps I'm taking the user-centric thing too seriously [22:55] CDot I reviewed the change; it is correct [22:55] Drusilla This is one of the reasons I'm having to use develop [22:56] CDot the issue is open in case the same fix has to be applied to Classic skin [22:56] CDot it can be regraded as "Normal" IMHO [22:56] PeterThoeny i think so too [22:56] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1881 [22:56] PeterThoeny Topic META:PREFERENCEs are lost when new topic created [22:56] PeterThoeny urgent/waiting [22:57] Lavr Yes. "Normal" seems right. Which still means Meredith can merge the fix in if it works. [22:58] Lavr Any reason not to merge the fix in? [22:58] SteffenPoulsen patternskin is out of sync in develop and twiki4 because of this? [22:58] Lavr For 1881 [22:58] Drusilla Yes, I believe so. [22:59] SteffenPoulsen ok [23:00] CDot Will is right, it ought to be fixed [23:00] CDot but it is not a showstopper [23:00] CDot as observed, no-one is using this feature [23:01] CDot though you can imgine that they might at some point [23:01] Drusilla Well, no one who started with Cairo, anyway [23:01] Drusilla I'm using it because I started with Dakar and it was a good feature. [23:01] PeterThoeny i just regraded Item2123 from urgent to enhancment [23:01] PeterThoeny "Search finds topics it should not find" [23:02] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2096 [23:02] PeterThoeny New topic missing from notification when renamed [23:02] PeterThoeny urgent/new [23:02] CDot is that even an enhancement, Peter? My inclination would be to discard [23:03] Lavr If I search for Kenneth and there is KennethLavrsen I may want it to find me. It is not clear that 2123 is a bug at all [23:03] SteffenPoulsen I don't like the idea that patternskin is drifting apart in twiki4 and develop .. also the latest TWIKICOLORSURL patch was applied only one place [23:03] PeterThoeny 2123, yes, discard is an option [23:03] Lavr I would discard 2123 [23:03] PeterThoeny actually, it could be an enhacnement, but with a new type=word [23:03] CDot but you are changing the spec, peter [23:03] CDot someone might be depending on that behaviour [23:04] Lavr Enhancing the spec. That is OK. That is compatible. [23:04] SamHasler are we going through Extension items as well or just Engine|Documentation? [23:05] CDot just Engine, and default components [23:05] PeterThoeny i put a note accordingly [23:05] Lavr Peter's proposal is backwards compatible. Peter can change the title and add the changed proposal and set it to enhancement. [23:05] CDot pattern skin, comment plugin, mailercontrib etc [23:05] Drusilla OH, yeah, comment plugin. [23:06] Drusilla It behaves wrong out of the box. [23:06] Drusilla (Much to my surprise) [23:06] Drusilla (in the middle of a demo, no less) [23:06] CDot Drusilla: bug number? [23:06] Drusilla Didn't post one yet. [23:06] CDot ok. I'll review when you do. [23:07] PeterThoeny any comments on 2096 [23:07] PeterThoeny ? [23:07] Drusilla lol. ~twiki4 doesn't let you log in [23:07] CDot I only just read 2096 for the first time [23:07] CDot so no comment yet [23:07] CDot need to think about it in the morning [23:07] Lavr But seems like a normal candidate. Not urgent [23:07] CDot (gosh, it *is* the morning) [23:08] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2090 [23:08] PeterThoeny Default values for fields not picked up in new form (TWIKI4 only) [23:08] PeterThoeny requirement/new [23:08] Drusilla Item2203 [23:09] Drusilla And, btw, we're currently getting the sidebar below the form on ~develop [23:09] CDot 2090: I fixed that, but couldn't close it, because ~develop was knacked. Will do so now. [23:09] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2090 [23:09] PeterThoeny sorry [23:09] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2086 [23:10] PeterThoeny EDIT_TEMPLATE appears to have to be fully qualified [23:10] PeterThoeny urgent/new [23:11] Lavr Meredith - did you fix 2086 in develop by any chance? [23:11] Drusilla I don't think so. I think I just worked around it [23:11] Drusilla I'm not crazy about going into modules I know nothing about [23:12] PeterThoeny is this a showstopper? [23:12] CDot no, it's a misunderstanding [23:12] Drusilla I don't know what the definition of a showstopper is. [23:12] CDot that is not the way EDIT_TEMPLATE works [23:12] CDot probably a documentation fix [23:12] PeterThoeny ok, doc question [23:12] Drusilla pardon?! [23:12] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2019 [23:12] * CDot looks for EDIT_TEMPLATE in the docs [23:13] Drusilla That *is* the way it works [23:13] PeterThoeny Template login broken sometime after 9648 [23:13] CDot no [23:13] PeterThoeny urgent/waiting [23:13] Lavr 2019 has a comment that ML needed to test more. [23:14] PeterThoeny can anyone reproduce 2019? [23:14] CDot yes [23:14] CDot it seems to be what is happening on ~twiki4 [23:14] PeterThoeny ok [23:15] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1560 [23:15] PeterThoeny referencing nonexisting favicon.ico in from-Cairo webs [23:15] PeterThoeny urgent/waiting [23:15] wbniv clearly not urgent [23:15] PeterThoeny agreed [23:16] PeterThoeny actually, favicon should be one per site by default [23:16] PeterThoeny and possible to redefne per web [23:16] Lavr I am having my error log flooded with warnings about missing pub dir for favicon file so it is annoying and it would be nice if it was addressed somehow eventually. [23:16] wbniv PeterThoeny: agreed [23:16] wbniv in fact, that's what i thought it was [23:17] CDot oh, is that what is causing that? [23:17] CDot it is *really* irritating [23:17] PeterThoeny a simple fix is to set it in prefs to be global [23:18] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2012 [23:18] PeterThoeny If a topic is locked, RCS doesn't tell you about it [23:18] PeterThoeny requirement/new [23:18] Lavr That would do it for my installations. I don't mind the favicon. I mind the error_log flooding. [23:19] PeterThoeny showstopper? [23:19] PeterThoeny 2012 [23:19] CDot 2012 only affects Windows, and is also fixed [23:20] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1843 [23:20] PeterThoeny A 1.2 version of a topic cannot be deleted (spam) with cmd=delRev [23:20] PeterThoeny urgent/new [23:21] PeterThoeny delRev on 1.2 is a special case: delete ,v and save [23:21] PeterThoeny that is how cairo worked [23:21] Drusilla This relates to the issue of being able to restore to a previous version [23:22] Drusilla Since delRev wont' work at all if the spammed topic has been edited. [23:22] Lavr Read carefully the report. The problem is deeper than what the initial report is saying [23:23] Lavr TWiki4 handles in general very badly topics without ,v files. [23:23] CDot I know what the problem is, and it needs to be researched and fixed. Anyone volunteering? [23:23] Drusilla Oh. That's different. You can't delRev if there isn't a previous version [23:24] CDot no volunteers? ok, I'll add it to the list. Next? [23:24] PeterThoeny showstopper? [23:24] CDot no, it's not a showstopper. [23:24] CDot just very irritating [23:24] Drusilla Not a showstopper for those who have been spammed? [23:24] PeterThoeny http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1980 [23:24] PeterThoeny Login text remains untranslated [23:24] PeterThoeny urgent/new [23:24] Lavr As long as we make sure always to distribute all ,v files it is not a showstopper. [23:25] Lynnwood hey, i just got back [23:25] PeterThoeny ok, so "normal" for 1843 since ,v usually exist [23:25] PeterThoeny what about 1980? [23:25] wbniv 1980: not urgent [23:25] wbniv not terribly new either, really? [23:25] Lynnwood regarding ,v files, it would be _nice_ to have twiki tolerant of their absense. [23:25] Lavr 1980. Careful. If you change language you change realm string and that would mean you have to login again. [23:26] Drusilla rcs is a frequent issue in #twiki [23:26] CDot 1980 is outside TWiki scope [23:26] SamHasler we're half way through the list after 40 minutes [23:26] CDot gawd [23:27] SamHasler is everyone happy to continue? [23:27] PeterThoeny we are getting at older entries now [23:27] PeterThoeny continue, or stop? [23:27] PeterThoeny i'd suggest to stop [23:28] PeterThoeny meaning, no more showstoppers [23:28] PeterThoeny ? [23:28] CDot I'm not getting anything out of this, personally [23:28] CDot except more tired [23:28] * dot--- (n=twiki@thwackety.plus.com) has left #twiki_edinburgh [23:28] SamHasler we can review items again quickly at the begining of next weeks meeting [23:29] PeterThoeny ok lets stop here [23:29] PeterThoeny actually [23:29] PeterThoeny one item, http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2125 [23:29] PeterThoeny seems to be in twiki4 [23:29] PeterThoeny i see a compatibility issue [23:30] PeterThoeny i suggest to revert and add a new parameter to control the format [23:31] wbniv i suppose that would be easier than trying to handle the change in an upgrade script [23:31] Lavr So the breadcrumb with non-wikiword topics in the "path" would not be linked. [23:31] wbniv well, we could fix the skins [23:32] PeterThoeny better to keep current spec and add a new format="" for the special case of twiki apps [23:32] wbniv but that doesn't deal with previous content issues [23:32] PeterThoeny i mean to revert to the default [[web.topic][topic]] format that we had before [23:32] wbniv PeterThoeny: to my previous comment, not yours [23:32] wbniv sorry :) [23:32] PeterThoeny ok [23:33] PeterThoeny we are at 150 min, way over the 90 min [23:33] Lavr Reverting seems the right thing to do here. I do not see that the lack of this fix is anything else than a nice-to-have [23:33] PeterThoeny can we close? [23:33] SamHasler yes lets close [23:34] PeterThoeny except we should talk about release date [23:34] PeterThoeny 9 may target ok? [23:34] PeterThoeny meaning next tue [23:34] CDot well, if you think that all the fixes will be in by then [23:35] PeterThoeny or, work this week, decide next mon [23:35] PeterThoeny build tue [23:35] PeterThoeny test wed [23:35] PeterThoeny release thu [23:35] PeterThoeny does that sound ok? [23:35] Drusilla I do hope "normal" bugs will get fixed at some point [23:36] CDot Drusilla: I fix them. You fix them. They get fixed. Eventually. [23:36] PeterThoeny yes, i am concerned about the quality reputation of twiki [23:36] PeterThoeny on schedule, sounds ok? [23:36] PeterThoeny reasonable? [23:37] Drusilla I guess I feel that bugs that conflict with the doc are important [23:37] CDot are you setting this date because you are planning to do the build? [23:37] wbniv no, i am [23:37] wbniv i can do it whenever [23:37] PeterThoeny basically a question for will [23:37] PeterThoeny and i can do the doc on twiki.org next week [23:37] wbniv we need to give some time to translators before each patch releas [23:38] CDot yes [23:38] PeterThoeny who is asking the translators? [23:38] wbniv SteffenPoulsen: [23:38] CDot I cannot commit to delivering any bugfixes this week [23:38] CDot which is why I will not commit to that date [23:38] CDot that doesn't mean they won;t get done, of course [23:38] CDot just that I personally cannot commit. [23:38] PeterThoeny ok [23:39] SteffenPoulsen I will write translators with 9 may as a tentative date tomorrow [23:39] PeterThoeny thanks steffen! [23:39] PeterThoeny lets close the meeting then unless someone brings up something else [23:39] SamHasler minutes? [23:39] Drusilla hours [23:40] SamHasler ha ha, sorry everyone, I'll try to keep it sorter if I'm ever given this responsability again [23:41] PeterThoeny ok, thanks all for the commitment and for hanging in there so long time :-) [23:41] PeterThoeny ttyl [23:41] Lavr Good night. [23:41] SteffenPoulsen yep, same to you .. see you around [23:41] SamHasler I can provide a irc log of tonight [23:41] PeterThoeny thanks sam for facilitating [23:42] SamHasler can someone else update the topic? [23:42] PeterThoeny yes, who is/was taking minutes? [23:42] Lavr I arrived late so I did not this time. [23:42] SamHasler um, no-one :| [23:43] Lavr And I will sleep in 2 minutes. 1.43 AM here [23:43] PeterThoeny good night kenneth [23:43] PeterThoeny any volunteer to update EdinburghReleaseMeeting2006x05x01? [23:45] SteffenPoulsen I will do it happily, but it will only be after work day tomorrow [23:45] PeterThoeny sounds good [23:45] PeterThoeny thanks! [23:45] SamHasler I've checksed my scrollback and I haven't got the hole meeting [23:45] SamHasler does anyone else? [23:45] Lynnwood I can post the log. [23:45] PeterThoeny thanks [23:46] SamHasler thanks Lynnwood [23:46] Lynnwood i _may_ be able to start on the note LATE tonight. i will if i can. [23:46] CDot okey-doke. Lovely talking to you all. Sleep well, and see you in the multi-branched morning!