Session Start: Mon Aug 27 22:02:06 2007 Session Ident: #twiki_release [22:02] * Now talking in #twiki_release [22:02] 'evening all [22:02] Good evening [22:02] evening Lavr_ [22:03] Looks like we have a quorum. Shall we start? [22:03] fine [22:03] excellent - please proceed [22:03] Steffen can you facilitate? Then I take the notes [22:04] surely [22:04] Lavr_: I take it we don't need to review outstanding actions? [22:04] We did not carry any over from last time. [22:04] cool [22:05] there are 4 points to the agenda: WYSIWYG, SimpleOperatorsInIF, Urgent Bugs, TWiki Release 4.2 [22:05] ok; WYSIWYG [22:05] you have all read my missive, I think [22:05] * PeterThoeny has joined #twiki_release [22:05] note that all the bugs coming in are really helpful [22:06] but many will *not* be fixed, as they are editor bugs [22:06] and are not within my control for this release [22:06] CDot: are they pushed upstream? [22:06] hi arthur, crawford, koen, kwang, kenneth, soronthar and steffen [22:06] not yet; we need to do so [22:06] hi peter [22:06] sorry for the delay [22:06] hi Peter, we just started [22:06] hi peter [22:06] no worries, we have started [22:06] out of another meeting, and no lunch yet [22:06] * gmc sympathizes [22:06] Yes. Now that we use it many will come in. We have to benchmark against Kupu when making decision here. Kupu is not perfect today. If we get an improvement we should be happy. [22:07] the bugs I *can* control are those in the tranlsator [22:07] and they affect *both* editors [22:07] any heads up after michelb's story? [22:07] ArthurClemens: you mean about Dojo? [22:07] who is taking notes, who is facilitating? [22:07] yes [22:07] Steffen Fac - Lavr notes [22:07] PeterThoeny: SteffenPoulsen , Lavr_ [22:07] no, nothing to add, really [22:08] michel only goes for dojo [22:08] (FYI: for those who did not follow IRC today, Buffa came along and shared some of his experince on Wysiwyg: http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2007-08-27,Mon&sel=192#l188) [22:08] Michel has been focused on Dojo, and that for SweetWiki [22:08] we wrote them down [22:08] he [22:08] tks [22:08] at http://twiki.org/cgi-bin/view/Codev/ReplaceKupuWithTinyMCE [22:09] so basic question is: Feature freeze or bug fix? how do ppl feel? [22:09] the auto-save point is a good one, but not a showstopper IMHO [22:09] well, I'm personally more comfortable with TinyMCE than Kupu [22:09] I guess the main problem in the scope of 4.2.0 will be how to handle when you copy and paste into TMCE. [22:10] I would have liked a usability expert to reconfigure it, perhaps [22:10] We cannot make it perfect in short time - it will be a matter of getting it tolerable. [22:10] i think the most visible improvements have been those to the WysiwugPlugin, so for me it is not clear whether kupu > tinymce or vv [22:10] gmc: dead right [22:10] I haven't had a scrutinous look at it [22:10] although with cdot's customisations of tinymce i tend to favour tinymce at this point [22:11] I think the speed is a telling factor [22:11] the current kupu integration is hurting the twiki project, so anything that is more stable is good; therefore i support the idea of replacing kupu with crawford's tinymce integration for 4.2 [22:11] it is much smaller, and loads a lot faster [22:11] but more stable? only testing can be sure of that [22:11] speed is key, as you know, wiki wiki means quick; that should apply also for the editing experience [22:12] the copy-paste problem is going to bite, for sure [22:12] (this is they key plus factor of wikiwyg) [22:12] we need a good answer to that [22:12] I'm all for tiny as well - but of course we are a bit dependent of the amount of ressources that CDot can throw after it [22:12] so actually we don't know if it will be good enough [22:12] well, right now my client is very happy with the work so far [22:12] an editor that does not destroy content is better than an editor without good copy&paste support [22:12] they obviously have a limited requirement [22:13] Peter. The copy/paste problem - see here - http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4507#r1 [22:13] since the editor is an extension, a new version can be made available after the 4.2 release [22:13] so, is not a copy/paste problems, is a content-destruction problem. [22:13] So we have a copy/paste problem AND a destroy bug to chase. Hopefully a fix can be found so this sort. [22:13] what destroy bug? [22:13] or do you mean copy/paste? [22:14] Soronthar. It is "destruction" that happens as a result of copy/paste. Let us not play with words. [22:14] actually, it isn't. The problem is due to the paste importing HTML tags [22:14] ok [22:14] oic [22:14] so the translator in fact isn;t destroying *enough* [22:15] it need to strip out the font tags and spans [22:15] and that's rather tricky [22:15] as who knows if they were intended or not? [22:15] If the copy/paste removes too much formatting then it is much easier to live with than what we see in Item4507 [22:16] can't we make the paste simpletext, remove all the tags? [22:16] CDot: this messing up becomes visible only after saving? [22:16] crawford: is it possible to add some marker to each and every html tag that was in the original tml so that it is easy to identify what was there when you do the reverse translation? [22:16] the problem is a fundmental one with editors in different environments. You will experience similar effects pasting from OOffice into Thunderbird. [22:16] I am used to remove all formatting from text I want to paste [22:16] in a text editor [22:17] PeterThoeny: no. [22:17] Normal users will not paste via a text editor. [22:17] perhaps the wysiwyg edititor can do the same [22:17] strip off all formattig [22:17] I am fine with pasted text becoming plain and then you have to apply formatting again [22:18] i don't know.. [22:18] a lot of people expect copy&paste to work and keep formatting [22:18] that's extreme [22:18] there are some options in TinyMCE to help with pasting [22:18] they have had this problem for a long time [22:18] we maybe just need to explore it more [22:18] it has a huge number of config options [22:19] this discussion has the potential to become very technical - I think we should focus on how to move the item forward in general [22:19] crawford, idea: on tml>html, change a to [22:19] on htnl>tml, watch out for "twiki: keep_html" [22:19] PeterThoeny: ideally, yes, but it doesn't work for a variety of reasons [22:19] to me it seems we can all agree it is an attractive editor, so we should probably go with it for two weeks, report and fix the bugs we can (give it lots of TLC) and take a new look at the status then? [22:19] I will explain offline if you want [22:19] * terceiro has joined #twiki_release [22:19] yes, offline please [22:20] SteffenPoulsen: i remember sven planning the beta a week from now [22:20] Steffen, I am fine with this [22:20] SteffenPoulsen: good idea; even better if I can get some coding help [22:20] I am all for continuing the integration of TinyMCE into TWiki INSTEAD of Kupu but it is a condition that we get an Edit Raw link at the bottom to enable copy paste of raw topic content and to sort out garbage [22:20] esp.on the javascript side [22:20] hi antonio! [22:20] CDot: perhaps I can jump in [22:20] ArthurClemens: I would be glad of it! [22:20] having someone else exploring the config of TinyMCE would help a lot [22:21] there are lots of callbacks that *might* be useful [22:21] ko, let's talk this through after meeting [22:21] personally I can't commit to anything there, I'm afraid - but much appreciated Arthur :-) [22:21] Done! [22:21] ok - next item: SimpleOperatorsInIF [22:21] Wait! [22:21] I want to make sure we agree on the Edit button strategy. [22:22] [22:22] * CDot likes shift+click [22:22] though edit raw is fine too [22:22] The proposal is that when TMCE is enabled the Edit becomes TMCE editor [22:22] The WYSIWYG button at the top is removed [22:22] yes, it should be only 1 button [22:22] yes, two buttons is confusing [22:22] It should be just edit [22:22] The WYSIWYG at the bottom is replaced by "Edit Raw" sitting next to "View Raw". [22:23] casual users should just use one editor [22:23] I can support a single edit button as well [22:23] The Edit Raw at the bottom is for the advanced and for sorting out trouble when you have copy/pasted some garbage in [22:23] +1 to single edit button, with an " [22:23] edit raw" at the bottom [22:23] the edit raw is for geeks, hence could be a shift+edit and/or a setting in user's homepage [22:24] NO! [22:24] _and_ then, [22:24] you need to be able to choose per edit session what you get [22:24] You need to be able to see the button. Shift click is too geek. [22:24] new alternatives are still thrown into the discussion so let's keep it open - we can all agree we want as simple an edit interface as possible [22:25] The Edit Raw will not only be for geeks. It will often be needed for normal users because TMCE will not be perfect [22:25] we should try to lift the veil that "raw TML is for geeks". [22:25] "Edit Code" perhaps? [22:25] 'edit raw' goes nicely with 'raw view' imho [22:25] the "edit raw" link might be a good until the editor is stable [22:25] As Kenneth has preached, if you put the option in plain sight, maybe someone curious will use it and make wonderful things. [22:25] Edit Raw is good because it mirrors View Raw. [22:25] e.g. we add it temporarily [22:26] we will have different ideas next year [22:26] One fine day when we have the perfect Wywiwyg editor then we can remove it. But that will not be 4.2.0 [22:26] Lavr_: that'll be 5.0, when we've abandoned TML and go for storing HTML :) [22:26] sounds like consensus to me - next item? [22:26] I'm forced to agree. Until we have tested a *lot* more, we can't be sure. [22:26] i see we have agreement on the "edit raw" button at the bottom, at least for 4.2.0 [22:27] OK. We have a decision then. I am happy. [22:27] ok - next item: SimpleOperatorsInIF [22:27] just for the record, what _is_ the decision? [22:28] go with tiny if at all possible, one edit button [22:28] everybody helps on the TLC part, arthur assists in js [22:28] clear, tnx, sorry for the interruption [22:28] np [22:28] CDot introduces SimpleOperatorsInIF [22:29] * CDot is waiting for questions [22:29] i like it.. [22:29] * CDot has his asbestos underwear on [22:29] my only objection would be procedure-wise [22:29] yes, I'm very concious of the procedural issues [22:29] i take crawford word that this is a low risk enhancement; it is supported by unit tests; i suggest to keep the feature [22:30] to which i happily agree, as long as we make it clear that it shouldn't become a habit [22:30] even though it overlaps with Spreadsheet? [22:30] I am not the one to be stringent [22:30] Maybe we should just decide that this is a means to solve a bug related to template dependencies on plugins [22:30] well, it solves several problems, but there's a longer term Q about how we "do things" in the standard templates [22:31] i.e. do we depend on plugins, or do we try to avoid that dependency [22:31] What we should not start on is any new refactorings of templates now! [22:31] an overlap with spreadsheet is no problem, because it is a bit of a hack to use spreadsheet for this kind of things imho [22:31] not about to, don;t worry [22:31] :-) [22:32] anbody has objections/feedback on the SimpleOperatorsInIF feature? [22:32] none from me :-) [22:32] great feature [22:32] else we go to next item [22:32] seems we'd have to be hard pressed to come up with arguments why it is a bad idea/implementation - I like it as well [22:32] i like them, simplyfies the syntax, keep em! [22:32] good [22:32] OK. because it solves an issue and is contained within a very small "feature room". [22:32] OK, next item is the meeting killer: Review Urgent Bugs [22:33] some manual labour is needed in reviewing Bugs, I will try to give it a shot the next week personally [22:33] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker [22:34] Note that I updated ReleaseBlocker so it now only shows engine and default extension related bugs that are urgent [22:34] how does it work, do we run by them 1-by-1..? [22:34] And it is implemented with the new query search [22:34] i see 2 KupuContrib bugs, are they still pertinent? [22:34] I suggest we skip all the new TMCE and WYSIWYG bugs. We know the owner - right CDot? [22:35] TinyMCE/wysiwyg holds 6 bugs currently (mainly cdot), 3 are I18N bugs waiting mainly for RichardDonkin [22:35] sadly, yes [22:35] The first I would like to see an owner for is... Item4048 EditTablePlugin: Password in URL params after template login [22:35] I'll take it [22:35] it was raised on the security mailing list so that is why it is being kept urgent [22:36] Soronthar thanks [22:36] thanks Rafael. be warned, it's fairly ticklish code! [22:36] i would like to pick up a bug or two, as promised, but stil making up my mind which are suitable [22:36] gmc: all the hard ones? ;-) [22:36] grin [22:37] well i can take on 4509, which seems simple enough .. ehrmz.. very hard indeed! [22:37] Item4510 Remove inline scripts is next to talk about. Arthur you raised it. [22:37] thanks Soronthar! [22:37] are you working on it yourself. [22:38] I don't have a clear solution for a cases on that item [22:38] for instance WebTopicCreator is full of inline script [22:38] for ages now [22:38] I would like to have someone look into http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item4439 - it looks a bit strange to me [22:39] (it is not set as a release blocker currently though) [22:39] so I will take a closer look at 4510 to see what the implications will be [22:40] excellent, thanks Arthur [22:40] On 4510 - does someone have any specific places where these scripts are regarded as a show stopper? [22:40] this guy needs to write td>INCLUDE

[22:40] CDot I guess the item was raised as a reaction to a email on the ML today [22:40] if you disable inline scripts in configure you will get red warnings [22:41] I never unchecked this before [22:41] Hmm. OK that seems a problem. I never unchecked this either [22:41] * CDot is reading [22:42] but javascript is needed for better user experience regarding WebTopicCreator [22:42] Yes I agree here. [22:42] * RodBeckstrom has joined #twiki_release [22:42] Hi Rod [22:42] hi rod [22:42] yes, but only if there's a fallback [22:42] so the question is really: can we move inline script to included script files? [22:42] cdot++ [22:42] my main concern is testing [22:42] I am conscious of fallbacks [22:42] i just helped rod get on irc [22:42] hi Koen! and team, great to c u guys here [22:42] because we double the required testing [22:43] we are sitting next to each other [22:43] browser + JS and browser-no-JS [22:43] up to now I have tested all scripts for fallbacks [22:43] how does this tie in with item4378? [22:43] hi Rod [22:43] since we lack testers already, adding new modes that have to be tested sounds..... risky [22:43] default templates may not contain javascript, but default topics may? [22:43] hi rod! welcome! [22:44] gmc: huh? [22:44] anything in the release *has* to work [22:44] doesn;t matter if it's code, template or topic [22:44] even the registration page has javascript [22:44] or doc [22:44] hi arthur [22:44] wonder how that works without inline script [22:44] good q [22:44] I have no idea [22:45] no problem to use js as long as there is a graceful fallback [22:45] FYI, I'd like to propose we have a twiki marketing meeting on IRC and phone every other Monday, staggered with this release meeting [22:45] AFAIK, the only thing with the registration page is that the Wikiname is not put automatically [22:45] the reg page is a good example: if js os turned off user still can enter the wikiname manually [22:45] if js is off [22:45] am just curious if same time as this next Monday can work for some of you (Arthur, Kenneth, Koen, Carlo, etc.) [22:45] my only point is we have to (test* all these failovers [22:46] Rod agenda here http://twiki.org/cgi-bin/view/Codev/FreetownReleaseMeeting2007x08x27 we are walking through urgent bugs [22:46] hi Crawford! we missed by phone but at least can meet here [22:46] RodBeckstrom: i will have to see, monday evenings are kind of bad for me, but let's discuss this later! [22:46] great idea rod (works ok for me) [22:46] RodBeckstrom: :-) [22:46] I will back off for now and market the marekting meeting later- thanks Kenneth [22:46] :) [22:46] :) [22:47] great to see so many smiley faces here [22:47] Related question: Is there any way we can automate the testing on browsers? Anyone knows a free tool (or at least free to OSS projects)? [22:47] I don;t mind inline script, as long as (1) there is a failover and (2) it is tested [22:47] Soronthar: JSUnit can be used; but WWW::Mechanize is the most common [22:47] any way we can *easily* automate test, that's it. [22:48] no, it's not *easy* to automate [22:48] we do have JSUnit as contrib [22:48] because of the complexity of the results [22:48] Let us seperate the two. This one is concerning if things work when {AllowInlineScript} is disabled in Configure (security tab). [22:48] yes [22:48] no! [22:48] it is not nice to be slapped with red warnings [22:48] it's concerning if the browser has no JS support [22:48] Kenneth, please add an item 5 to the agenda on TWiki marketing call next Monday, Sep 2 on IRC: twiki_marketing [22:49] one more minute for js discussion before we should press on to item #4 on the agenda (Coordinate TWiki Release 4.2)? [22:49] CDot: that is easier, but user experience will suffer [22:49] CDot yes but that is another bug item that should be raised then. This one is a problem even with the browser JS enabled. [22:49] please clarify the bug item, then [22:49] removing that warning is trivial [22:50] re Item4510, i think Arthur would look into which topics are affected, and then we can discuss how to attack the problem.. right? [22:50] Rod: OK [22:50] agreed [22:50] excellent, time for last item? [22:50] excellent! [22:51] deadline for 4510? [22:51] author decides, hopefully one week will do the best of it? [22:51] I will look into in the next days. Let's say 1 week [22:52] Next worth discussing is Item4509: Prevent entry of [ characters when renaming topics [22:52] ok, put me down for that one .. [22:52] that came in today [22:52] gmc takes 4509 great [22:52] thanks koen! [22:53] a couple of places are affected: TWiki.pm and core javascript [22:53] Item4081: Broken Links to Topics and Subwebs I will take care of (Doc) [22:53] i will take a look at Item3652 too, i like umlauts [22:54] thank you very much gmc :-) - Lavr, if we need to touch coordination at all we should leave bugs base now - but it is alright with me to spend the time on bugs [22:54] I have no more to talk about. rest is CDot and Richard [22:54] excellent :-) next item: Coordinate TWiki Release 4.2 [22:54] * CDot is worried about the number of "Urgents" sitting waiting for feedback [22:54] sojme are probably real bugs [22:55] They should be on the list on ReleaseBlocker [22:55] perhaps [22:55] They are. 4445 Wysiwyg. Waiting for Carlo [22:55] 2032 waiting for Richard [22:56] oh, ok, n.m. then [22:56] they need testing, a beta will assist in that (I hope) [22:56] I see the release mangler is on top of th problem :-) [22:56] anyway, on the release: Kenneth suggests a beta in one week [22:57] You should all know that I regularly post unit test runs in perl 5.6.1 on Item4431 [22:57] I have been running the tests on Windows too, though not posting [22:58] 797 of 818, IIRC [22:58] On beta - yes. Assuming we get the non-TMCE nailed I suggest a beta in one week to get more test exposure of TMCE [22:58] I don't know about the validity of such a timeline, but we could do another release meeting in a week and see if it is time for a beta? [22:58] clash with mktg meeting [22:58] darn [22:59] Sunday? [22:59] works for me [22:59] For sure we will need more than one beta. But basically I think we should let Sven build the first in one week. [22:59] If he has the time [22:59] We also need to update translations before the actual release [22:59] good point [23:00] first is a string freeze at some point [23:00] Yes. Maybe we should declare string freeze soon. Maybe with the beta. Then the translators can use the beta for translations [23:00] TinyMCE also has translations [23:00] I don't think we even have a list of translation maintainers [23:00] we need to feed the internationalisation setetings into it somehow [23:00] terceiro: has a list, I think [23:01] only official contribs are translated [23:01] (I believe) [23:01] yes, we have a translator list [23:01] on authors: most are in authors topic and in the .po files, but there's a translator mail attached to one of the translation topics that holds them all [23:02] in the actual .po files there are the translator names [23:02] we should alert the translaters ahead of time that the string freeze is coming up [23:02] declaring string freeze with the beta sounds like a good plan - one week to finetune strings before that [23:02] and there is a script under tools/ that list the translators [23:02] and allow at least 2 weeks for string freeze before production release [23:03] hmm, I don't see any contrib in the translation file, only skins [23:03] antonio, are you coordinating the translations again for 4.2? [23:03] PeterThoeny: I think 2 weeks is not enough [23:03] if we decice on a string freeze, it must be actual freeze [23:04] not almost freeze, but absolure freeze [23:04] absolute freeze [23:04] agreed on absolute freeze [23:04] but we are not ready yet [23:04] no, but 2 weeks are good aiming for - we tend to get our production release delayed and authors submit late, it works. Missing translations can be downloaded seperately afterwards [23:04] a lot more doc fixes need to be done [23:04] and yes, I am going to coordinate translations for 4.2 [23:04] CDot. TMCE - can it string freeze in one week? [23:04] (ps, are we going to fork of a 4.2.0-RC branch already, or is that for next release?) [23:04] terceiro: excellent, I'll leave the timings to you, then :-) [23:04] thank you very much antonio! [23:04] our code will not include TMCE in the translations [23:05] Does anyone need MAIN free for new feature now? Or do we wait for the beta? [23:05] it seems translation texts from contribs are not put in the pot file [23:05] ArthurClemens: yes, they aren't [23:05] up 2 now, at least [23:06] sounds like an action item for someone? [23:06] everything that is in the release MANIFEST is included in the translation extraction scan [23:06] so, currently we only translate the main TWiki distribution [23:07] Does it follow the includes in the MANIFEST? [23:07] Lavr_: yes [23:07] Good. Then it should also get the default extensions. [23:07] Lavr_: yes [23:07] TMCE has no strings [23:07] I remember vaguely it only picks up MAKETEXT, not make_text() [23:08] CDot: does so [23:08] CDot: hover over the icons.. [23:08] gmc: that's the editor. [23:08] ArthurClemens: it picks MAKETEXT in topics and templates [23:08] see the moxicode website for the translations files [23:09] * gmc shuts up again [23:09] some plugins write make_text() in perl files [23:09] i don't know about make_text() [23:09] Do we have many make_text() in the default plugins? [23:09] CDot: do those translations use TWiki language settings? [23:09] hmmm we are at +9 ... we have the translation issue in the air, terceiro holds the ball - any other issues we could think of in releation to the release? [23:10] ah, its maketext() [23:11] looks like no default plugins are using that [23:11] No more: Next is to talk to Sven. Decision is beta in one week, we assume more than one beta, string freeze from release of first beta, antonio is in charge of translations. [23:11] COOL! [23:11] Agreed on COOL! :-) [23:11] And I will write the release notes the next days. [23:12] COOL++ [23:12] I really want to thank the community for really stepping up and closing a lot of bugs lately. [23:12] just to be sure: are we on string freeze? [23:12] nope, when the beta goes out, strings are frozen [23:12] string freeze from release of first beta. Ie. people have ONE week. [23:13] SteffenPoulsen: Lavr_ : ok, agreed [23:13] We need Sven to sign up to building the release. He is working on new release scripts etc so I will not touch that. [23:13] I would ask for a "warn when changing strings" period before absolute string freeze [23:13] ArthurClemens: no, we need to work out how to do that [23:13] I am very happy that sven stepped in so we are two to share the task [23:13] so we can somewhat start the translation process [23:14] ok, fresh out of agenda items .. I agree with Lavr, TWiki have been spinning since Rome, happy to see it lively again :-) [23:14] no there was item 5 added by rod [23:14] We have item 5. [23:14] Rod [23:14]