Session Start: Mon Apr 03 21:59:54 2006 Session Ident: #twiki_edinburgh [21:59] * Now talking in #twiki_edinburgh [22:00] Good evening/morning all [22:00] kenneth, i will join a bit late, in about 10 min [22:00] ok [22:03] ah, someone else did show :) [22:03] hi guys [22:03] Hi Will [22:03] shall we postpone to :10 ? [22:03] * CDot has joined #twiki_edinburgh [22:03] Will make coffee then :-) [22:04] CDot: we're postponing to :10 [22:04] but i think it'll be a short meeting [22:04] I'm not hanging around until 10 [22:04] what's on the agenda? [22:04] :10 [22:04] in 10 minutes [22:04] k [22:04] Now 6 minutes [22:04] speak to you in the other [22:05] Agenda is [22:05] * Follow-up on develop.twiki.org server move [22:05] * TWiki 4.0.3 release discussion [22:06] * wbniv changes topic to 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x04x03' [22:07] also, i just added [22:07] * CSS-related issues (eg, Support.EerieWierdnessWithFirefox among other reports, this is just the latest) [22:14] i am back [22:14] sorry for the delay [22:14] And I have my coffee :-) [22:14] i have now a 1.5g dsl connection [22:15] and will get voip [22:15] no more telco [22:15] congrats [22:18] i got an e-mail from lynnwood, he is not joining today, or possibly at tail end [22:18] hi crawford, back? [22:18] ish [22:18] in another conversation [22:19] but listening [22:19] oic [22:19] well, it will be a very short meeting i think [22:19] I have started minutes [22:19] thanks! [22:19] first of all, my apologies for the late invitation [22:20] and for not realizing that down under, daylight savings is going into the other direction [22:20] making it impossible for sven to join [22:20] not sure what to do there [22:20] lets discuss that later [22:21] and start [22:21] * CDot has left #twiki_edinburgh [22:21] ---+ Follow-up on develop.twiki.org server move [22:21] * CDot has joined #twiki_edinburgh [22:22] what items are pending on develop.twiki.org server move? [22:22] gah, that one's going to be hard to address without sven, methinks [22:22] Emailing out seems to not be working yet [22:22] post-commit script [22:22] I have sent diagnostics to sven [22:22] both action items for sven [22:22] something to do with not having the right permissions to send mail [22:23] I was fighting with that also on my Motion SVN. [22:23] one more: change twiki-dev subscriptions from @ntwiki.ethermage.net to @develop.twiki.org [22:24] SF is also picky on who sends mails. [22:24] maybe you can advise sven how to solve it, lavr? [22:24] I asked him back then - maybe we have each our part of the jigsaw [22:24] Which distro is on the new box? [22:24] PeterThoeny: ? [22:24] i can handle the mailing list subscription change [22:24] is the new server a mail server as well, then? [22:24] * CDot didn;t realise [22:25] but i need to know what exactly the "from" address is from the commits [22:25] hmmm [22:25] Fedora core, i think [22:25] no [22:25] but redhat, anyway [22:25] I think that needs sven to get outgoing mail working [22:25] yes [22:25] OK. Then the settings are like mine which is a FC. [22:25] in theory, it should be develop@svn.twiki.org [22:25] 1. outgoing mail needs to work [22:26] yep [22:26] 2. twiki-dev subscriptions need to be fixed [22:26] i can do #2, but need to know the from address (probably user@develop.twiki.org) [22:27] one more action item for sven: add linked fastserver.net logo to develop.twiki.org home and bugs webhome [22:28] we promised to do that [22:28] anything else on develop.twiki.org? [22:29] is _much_ faster :-) [22:29] have they sent a logo? [22:29] yes [22:29] i already added the logo to twiki.org home [22:29] in that case, i'd recommend creating a bug report for that task, and attach it to the bug report [22:29] that was may be two weeeks ago [22:30] sven will read the action items [22:30] anything else? [22:30] ready for next item? [22:31] Yep [22:31] ---+ TWiki 4.0.3 release discussion [22:31] When I suggested to pull back 4.0.2 it had just been released, but before my email actually forwarded by SF and read by most of you hours had passed and it was too late. [22:31] I think the current download page with a zip and a small hotfix works OK. Easy to understand and easy to install. [22:31] If statistics from t.o. says that people are downloading both zip and fixzip then I see no hot urgentcy to release a 4.0.3 immediately [22:32] this affects only public twikis, right? [22:32] No. Both [22:32] The SPAM padding only public [22:32] but let's release 4.0.3 as soon as the css issues have been cleared up? [22:32] And the email addresses in forms only Intranets [22:33] But I think the small extra download on the page is very visible and easy to figure out. [22:33] there have been questions about whether we will provide a patch [22:34] ok, i can talk about that [22:34] and also asking if UpgradeTWiki works [22:34] You means the patch from 4.0.1 to 4.0.2? [22:34] aye [22:34] i responded to the guy's q on the release topic about an hour ago. i sent him a patch to test [22:34] i emailed him, that is [22:34] an hour ago [22:34] You made the patch so it includes new files also? [22:34] yup [22:34] -N [22:35] ok, keep it public, there are a number of interested people, and they need to kknow what is going on [22:35] i'd figure i'd let him test it first, tho :) and then post it [22:35] so put a note on the page "we are testing apatch right now" [22:35] ok, that's fine [22:35] good idea [22:35] on UpgradeTWiki; I looked at the code [22:36] done [22:36] and was left feeling rather hollow.... [22:36] ? [22:37] it needs someone to sit down and spend a solid day on it [22:37] then it would work again [22:37] but as it is, i wouldn;t trust it [22:37] when did it stop working? [22:37] I'm not convinced it *did* [22:38] but it is essentially untested [22:38] we do not maintain test records for it [22:38] it is not part of the release cycle [22:38] you are talking just about cairo > dakar upgrade, right? [22:38] no [22:38] any TWiki-X -> TWiki-X+N upgrade [22:39] so upgradetwiki on 4.0.1 to 4.0.2 is not working? [22:39] * SteffenPoulsen has joined #twiki_edinburgh [22:39] I didn't say that [22:39] I said it is *untested* [22:39] ok [22:39] so I can;t recommend people use it [22:39] i see two action items [22:40] 1. sanity check [22:40] it needs a solid day from someone, to (1) test it, (2) document it, (3) document the procuedre for testing it in the release cycle [22:40] 2. fix if needed (with note to lower expecations) [22:41] crawford, good point [22:41] CDot: shouldn't (3) be more like "add tests" ? [22:42] a sanity check can be done quickly, goal is to put a note to lower expecations in case there are issues [22:42] wbniv: c'est la meme difference [22:42] I noticed on #twiki that some expected more than it ever could like upgrading user topics to new format. [22:42] yes; that's what isn;t documented [22:43] Its "self-documenting" nature is not enough. [22:43] who as maintaining the script in the past? [22:43] GaJ (Martin gregory) [22:44] Hi Steffen - I am minutting. [22:44] we can ask him if he is volunteering [22:44] I *strongly8 doubt it [22:44] worth a try [22:44] he is in the process of winding up a company, and is a tad busy [22:44] oic [22:44] but we can always ask [22:45] I donl;t know who else might do it [22:45] I doubt Meredith would be interested [22:45] the upgradescript is independent of 4.0.3 adn can be done in parallel [22:46] Hi Lavr - that's great (and 'evening all .. didn't notice the -1h time shift, sorry, I see you are in full swing :-)) [22:47] who is going to ask gregory and meredith? [22:47] sevn should [22:47] sven [22:47] Martin is in Australia [22:48] ok, what else should go into 4.0.3? [22:48] besides the e-mail address issues? [22:48] CSS issues [22:48] First question. It the current 4.0.2 hotfix solution OK or is it urgent? [22:48] not that i know that the resolution is, but... [22:49] anyone know what the download numbers are so far? [22:49] (21:46:20) PeterThoeny: ok, what else should go into 4.0.3? - all Urgent and Requirement items currently open in bugs web ;-) [22:49] wbniv: Item #? [22:49] let me check on downloads... [22:49] Lavr: I think the hotfix is OK [22:49] http://twiki.org/cgi-bin/view/Support/EerieWierdnessWithFirefox [22:49] If the stats say that people also download the fix zip then I see no urgency [22:49] I think that is a good soln [22:49] many q's in #twiki [22:50] (about force-refreshing the pages) [22:50] other Support topics, as well [22:50] i'm not sure arthur knows the answer either [22:50] (heh, at least not yet) [22:50] package zip & tgz: 564 [22:51] but, this css issue does seem to be separate from the css issue on t.o as that's still cairo [22:51] or, does this *only* have with FF<1.5 ? [22:51] email fix: 14 [22:51] (i have 1.0.7 from debian stable) [22:51] wow, a huge discrepency [22:51] I'm not suprised [22:51] sorry, email fix: 27 (zip & tgz) [22:51] most people won;t see it as important [22:51] same diff :( [22:52] but is it that they don't see it as important or don't see it *at all* ? [22:52] if it's not important, then no "rush" on 4.0.3 [22:52] if they don't see it at all, then *rush* [22:52] I think the download page could be clearer [22:52] it's not obvious when you scan the page [22:52] ah, add a link to the patch underneath the zip | tgz download box [22:53] *in* the download box [22:53] underneath zip | tgz [22:53] [22:53] It is there. [22:53] no it isn't [22:53] *IN* the blue download box [22:53] i think it is much cleaner if we release a 4.0.3 soon [22:53] which is fine, too [22:54] question; do we release 4.0.3, or simply do a 4.1? [22:54] Any other hot issues that should be put in 4.0.3 also? [22:54] it seems to be we released a lot of enhancements with 4.0.2 [22:54] maybe we should be honest with ourselves, and call the next one 4.1 [22:55] but calling it 4.1 means people expect more features [22:55] there aren't enough enhancements to warrant a 4.1, tho [22:55] 4.1 after 4.0.2 with two small fixes. I think that makes no sense. We could have done 4.1 instead of 4.0.2. [22:55] which we do not have between 4.0.2 and 4.0.3 [22:55] aka 4.1 unless we add them [22:55] * CDot is just thinking of coming clean about the enhancements [22:56] * CDot doesn't like releasing enhancements in patches [22:56] the biggest enh was the pattern skin [22:56] I have an urgent need for the whitepsace stripping (from templates) to go in [22:56] If discussed the 4.1 vs 4.0.2 and decided for 4.0.2. And with just a few small fixes the next release cannot be called 4.1. [22:56] anyway 4.0.2 is done [22:56] I held off from 4.0.2 [22:56] but need it to go out [22:57] (comment plugin and mail in contrib are both currently broken because of it) [22:57] how much time needed for whitespace stripping? [22:57] how much risk? [22:57] it's done [22:57] It is a matter of testing. [22:57] yes [22:57] it is running in develop branch [22:57] and has been for quite a while [22:57] it sounds like it hsould go into 4.0.3 [22:58] since mid feb [22:58] I ran develop with it for a while and we found many many issues the first days. So it will need testing again. Not for a 4.0.3 in a rush release. [22:58] agreed [22:58] ok [22:59] so possibly release 4.0.3 quickly with just the e-mail fixes, and offer a patch for whitespace issue? [22:59] there are still many urgent and Requirements items against Engine [22:59] at least the set currently open should be closed for 4.0.3 [22:59] a patch for the whitespace issue is not an option, IMHO [23:00] the purpose of this meeting is to asses what should go into the release, and to fix a target date [23:00] it touches almost all the templates [23:00] right; my view is that all open Urgent and Requirement should be closed for 4.0.3 [23:00] that sound like risk involved [23:00] I would propose that we make the email fix download more visible including a link in the "blue box" and take it more easy with the 4.0.3 and include some more fixing in it. [23:01] I would *like* the whitespace fix to go in, but can be negotiated out of it [23:01] PeterThoeny: risk? risk in fixing bugs? [23:01] CDot: i'd prefer they get tested and go in [23:02] i wish the whitespace would have gone into 4.0.2 because that release already touched all templates [23:02] meaning customers with their own skin need to fix their skins again, and again [23:03] what other changes would you like to see for 4.0.3? [23:03] i'd like a resolution on the CSS issues [23:04] i get regular reports on that for twiki/org/index.html [23:04] PeterThoeny: I *think* that Arthur actually took the "toched" templates into 4.0.2 [23:04] so whitespace may be a non-issue [23:04] the important point about it is the *testing* [23:04] that would be cool [23:04] as Lavr says [23:04] PeterThoeny: but the issue on twiki.org has nothing to do with dakar css templates as it's still running cairo [23:04] PatternSKin is updates should be compatible and the same in both DEVELOP and TWiki4 [23:05] Besides the bad grammer I hope you got it. [23:05] not really [23:05] Arthur has kept the PatternSkin in sync on both DEVELOP and TWiki4 branches. [23:05] good [23:06] i am not sure if the css issue can be resolved [23:06] then the whitespace fix should be a non-issue [23:06] i investiagted today [23:06] Not for Pattern. [23:06] i'm not sure what the css issue *is* [23:06] me neither [23:06] is it limited to FF<1.5 or no? [23:06] ff 1.5 thinks it gets css as text/plain *somethimes* [23:06] what is the Item number? [23:06] i have the problem on t.o *all the time* with FF1.0.7 [23:06] oh, this is the firefox bug? [23:07] (or FF1.0.6, not exactly sure which) [23:07] CDot: we don't know [23:07] k [23:07] or at least, i don't know [23:07] I have seen the CSS issue on t.o. round the time when the tag plugin was added. [23:07] there are other reports on the net [23:07] but no clear solution [23:07] Clearing cache fixes it. Did the tag plugin add css changes? [23:07] i checked mime type settings on twiki.org, all ok [23:08] yes, clearing cache solves the issue [23:08] but if an evaluator sees twiki.org with this it makes a very bad first time impression [23:08] ah, clearing cache! not just force refresh [23:08] * wbniv tries that [23:08] I have only seen the issue when the css files have changed. So the people on t.o. that see it must have been there before. [23:08] as i have topics from t.o all the time with the wrong formatting [23:08] so we do not have a solution at this time [23:09] so n.a. for 4.0.3 release [23:09] * CDot is concerned that if there is a cache issue, it may also bit JavaScript [23:09] * Drusilla has joined #twiki_edinburgh [23:10] crawfod: what other fixes would you like to see in 40.03? [23:10] 4.0.3 [23:10] I see 8 urgent & Requirement. Just those. [23:11] and probably only 6 of those. [23:11] most outstanding bugs are against plugins that are not in the core set [23:11] do you want to go through the list? [23:11] no, not really [23:11] I just want people to fix them ;-) [23:12] Will you checkin the white space fix now or wait? [23:12] I will merge it now. The sooner the betterm I think. [23:12] maximum testing time. [23:12] I am willing to test it on my Motion TWiki also. [23:12] cool [23:13] but wait [23:13] that means we will not do a quick 2.0.3 release [23:13] it will be a regular patch release [23:13] is that ok? [23:14] it is for me [23:14] just asking to be sure we wnat that [23:14] If we make the email fix more visible on the download page incl blue box I think yes. [23:14] ok by me as well [23:14] y [23:15] ok be me if this is the wish of all (but having an uneasy feeling on lowering twiki reputation on quality) [23:16] A quick fix few days after also has a negative impact. [23:16] compare 350 downloads a day of new users vs 10 downloads of upgraders [23:17] the 350 users see the please patch the patch note [23:18] anyway, lets proceed as discussed [23:18] If it was easier to generate a release, i think you would get more support for that view, Peter [23:18] but it is still quite hard to generate a release [23:18] y, and i haven't had the time to finish automating it [23:18] there is a lot of infrastructure, but still not enough tests [23:18] and that is a big problem [23:18] but, eventually, i just want to perss a button and have it spit out a release [23:19] fully tested, of course ;-) [23:19] yup, that's part of it! [23:19] but it will be a long time (perhaps never) until we don't need the human testers to test out a candidate release [23:19] so, the resistance to 4.0.3 is simply the effort involved in generating a release [23:19] that half of it [23:20] the other half is, as lavr said, releasing a 4.0.3 *right* after 4.0.2 has negative perceptions, as well [23:20] well, I think I agree with peter on that point [23:20] I would rather have a single package that has everything [23:20] than have to patch a patch [23:21] so, you guys want me to do another build today? [23:21] but i am also sensitive to the effort involved [23:21] it's hard to see what's happened, however, without svn emails! [23:21] ..back from phone, sorry [23:21] if you could be sure of building *only* 4.0.2 + the template fix, then i would say "yes" [23:21] but I don;t think you *can* be sure of that [23:21] perhaps a goal for 4.0.3 could be >x test cases, done by >x different contributors, to signal that the new 4.0 foundation is now getting final and it's our intention to keep it stable where it is? [23:22] esp. without an svn/email log [23:22] SteffenPoulsen: it's fine to set goals [23:22] but leadershipp by example would be even better.... [23:22] There are always incomming bugs after a release and I think waiting a week or so will give a more bang-for-the-buck 4.0.3. Otherwise we will be talking 4.0.4 soon. [23:23] ok, no quick 4.0.3 release [23:23] but: i'd favor actually to hide the patch on patch a bit [23:24] who has login access to develop.twiki.org? just sven? [23:24] SamHasler: I do [23:24] * CDot has been fixing the commit scripts [23:24] thanks crawford [23:24] what was wrong with them? [23:24] erm; they didn't work? ;-) [23:25] CDot: agreed, nothing like doing the work right to set the example [23:25] so with 4.0.3 not going out anytime soon i will send out an announce for 4.0.2 [23:26] oh bugger, i had forgotten you haven't sent out an announcement for 4.0.2 [23:26] i was waiting for the decision [23:26] right right right [23:26] i just forgot :) [23:26] PeterThoeny: make sure lavr has fixed the page first [23:26] so the "patch the patch" decision is simple and clear [23:26] no, actually, on the download page i think we should _hide_ the patch on patch [23:26] i.e. don;t bother unless...... [23:26] But we should not hide the email fix. [23:27] and handle it just as a normal known issue [23:27] hum. OK, that works for me. Though it may piss off some public sites. [23:27] i do not want 10'000 downloaders see a "please patch the patch" [23:27] gives a bad first time impression [23:28] the installation notes point to the know issues page [23:28] You do not want 10000 downloaders complain about no email SPAM padding and email links on the users home page not working. [23:28] wbniv, you use macs don't you? any access to windows machines? [23:28] my mac is dead :( [23:28] :( [23:28] and no, no windows allowed here ;-) [23:28] i'm not going to pay US$300 for a windows license! [23:29] wbniv: GET A CHEAP, GENUINE ONE OFF EbAY.... ;-) [23:29] It is the "first impression" I worry about when you register your first user and see that the email link is broken and NOSPAM padding is ignored. [23:29] oops [23:29] a large percentage of the 10000 is for workplace use [23:29] Yes. And for the workplase use the broken email address is bad. [23:29] just not linking it? [23:30] I ask because I've been using autoit to automate testing for work, but it's windows only. I wonder if there's something similar for macs/*nix [23:30] SamHasler: there are lots of test automation tools for X [23:30] HTMLUnit is pretty common [23:30] i have to sign off soon [23:30] It does not create a mailto: link. And even worse. If the address is like hjfhf@inet.uni2.dk there is a mailto and it is broken. [23:30] the trouble with them is that they are very fragile [23:30] SamHasler: there's also something for perl that sven keeps pointing me at [23:31] It becomes a mailto:hjfhf@inet.uni2 [23:31] known issues will probably work alright (they have before) .. if it's too much support we can emphasize it again [23:31] we have been handling knwo issues by creating a topic of the ones worth highlighting, and linking from the known issues page [23:32] Lavr: I think we know the symptoms. The choice is stark; either (1) hide the fix away, so you have to look for it or (2) publiscise it, but play it down so it seems unimportant [23:32] http://twiki.org/cgi-bin/view/Codev/KnownIssuesOfTWiki04x00x00 [23:32] But the known issues page has normally not really given any solution you could easily download and install. [23:32] Lavr: Right, that could be improved in this case [23:33] personally I prefer (2) [23:33] not the know issues page, but a supporting page [23:33] * wbniv is now known as wbniv|bbi5 [23:33] or a bug report page [23:33] If we do 2. then all we have to do is leave things as they are. [23:33] I thought the wording you used on the 4.0.2 page was pretty good [23:33] that contains a patch [23:34] though needing to be a bit more visible. [23:36] i definitely do not want to see "patch the patch" link on the big blue download box [23:37] and i'd like to see the patch moved to a dedicated page [23:37] and linked from the known issues page [23:37] I disagree. That is not caring about your customer. [23:38]