Calendar:QA Chat:2007-08-30:Log

[18:30] <mschroeder> Let's start the QA chat.
[18:31] <mschroeder> You can find the agenda at http://wiki.mozilla.org/Calendar:QA_Chat:2007-08-30. But it is the same as last time. :)
[18:33] <mschroeder> We had a Test Day on Tuesday. Only a few bugs have been spotted.
[18:33] <Andreas> Ok, let us start with the proposed blocking bugs again
[18:34] <ssitter> hi folks
[18:35] <mschroeder> Andreas: Is the overlapping event boxes bug you filed a blocker? It is definitely a regression.
[18:35] <mschroeder> Bug 393969
[18:36] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=393969 nor, --, ---, michael.buettner@sun.com, NEW, After deleting an event, some events overlapps
[18:36] <Andreas> Oh, no blckingflag :-(
[18:36] <ulf> hi folks
[18:36] <ctalbert> hi
[18:37] <mschroeder> Omar B. filed a similar bug (bug 393994). Is it the same issue?
[18:37] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=393994 nor, --, ---, nobody@mozilla.org, NEW, Colliding events issue
[18:37] <Andreas> Yes, I think so.
[18:41] <Andreas> should we flag bug 393969 'blocking0.7?'
[18:42] <mschroeder> at least 0.7?... I would vote for 0.7+
[18:43] <mschroeder> any other opinions?
[18:43] <Andreas> 0,7+ is only for release drivers, or not?
[18:44] <ulf> that's what I'd recommend also. We should try to completely fix this 'war on boxes' thing for 0.7 - if possible.
[18:45] <mschroeder> 0.7+ = 0.7? + Cc daniel + convincing daniel it is ugly, a regression and Philipp should fix it ;)
[18:45] <mschroeder> I meant mickey.
[18:45] <mschroeder> not philipp
[18:45] <Andreas> thats sounds good!
[18:46] <ulf> Andreas, mschroeder: before someone complains - let's make it 0.7?
[18:46] <ulf> mickey is going to look into this anyhow
[18:47] <mschroeder> Andreas: Can you set the flag and comment? You reported the bug. :)
[18:47] <Andreas> Ok, I set the 0.7? flag and write a comment.
[18:48] <mschroeder> What about bug 394004?
[18:48] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=394004 nor, --, ---, nobody@mozilla.org, NEW, Two tasks (same date, length 0 minutes) on different calendars -> only one is visible
[18:50] <Andreas> Done, Daniel is CCed.
[18:50] <mschroeder> Andreas: thanks
[18:52] <mschroeder> 394004 will be resolved with 387402 but it's not sure if the latter will have a patch in time.
[18:53] <ssitter> firebot: bug 387402
[18:53] <firebot> ssitter: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=387402 nor, --, 0.7, nobody@mozilla.org, NEW, Events are hard or not selectable
[18:54] <ssitter> I don't think so. As I understand 394004 the tasks are shown stacked on each over instead of side by side
[18:56] <ssitter> btw, same happens for zero-length events
[18:56] <mschroeder> Andreas: Your opinion?
[18:56] <ctalbert_> I think these sound like two different things
[18:57] <ulf> but the zero length events painted one over another isn't even a regression
[18:57] <ssitter> I think the use case is very rare. should be fixed but maybe not a blocker
[18:57] <ctalbert> It is, since that would not happen without the war on boxes being fixed, I think.
[18:57] <ctalbert> I don't think the zero length event thing is a blocker either.
[18:57] <ulf> ssitter: +1
[18:58] <Andreas> Sorry, my chatzilla make some toubble :-(
[18:58] <mschroeder> also +1
[18:58] <ctalbert> We should keep this edge case in mind though because the way it will be re-reported will be "my events disappeared"
[18:58] <mschroeder> ctalbert: relnote keyword?
[18:59] <ctalbert> sure
[18:59] <ssitter> you are right, sb 0.5 also shows the events stacked on each other
[19:00] <ssitter> same with tasks
[19:01] <ulf> ssitter: I know, that's what I meant above with "not even a regression"
[19:02] <mschroeder> Should we leave the bug as is?
[19:03] <ssitter> handling of zero length events (including views) is also filed as bug 333362
[19:03] <firebot> ssitter: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=333362 nor, --, ---, nobody@mozilla.org, NEW, Figure out what a zero length event means, and check if all code does the right thing
[19:03] <ssitter> mschroeder: I would extend the bug for tasks and events and note that the issue already exists in 0.5 release
[19:05] <mschroeder> agreed. I'll add it later.
[19:06] <mschroeder> ssitter: You filed bug 394183. I think it should be a blocker.
[19:06] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=394183 nor, --, ---, nobody@mozilla.org, NEW, Task creation via double click in Task List is broken
[19:08] <ssitter> we probably should triage all bugs marked as regression to check if this are blockers or not
[19:08] <ssitter> yes, this one should be fixed
[19:08] <mschroeder> ssitter: Will you request blocking and cc daniel?
[19:09] <ssitter> k
[19:09] <mschroeder> thx
[19:10] <mschroeder> ulf: Any news on bug 392448 ?
[19:10] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=392448 nor, --, ---, nobody@mozilla.org, NEW, [Proto] Event dialog: date/time combo boxes: edited values not always saved
[19:12] <ulf> mschroeder: talked w. mickey about that one this morning and he said according to my findings it should be easy to fix
[19:13] <ulf> he said he wants try to fix that one
[19:13] <mschroeder> good, then we'll leave it 0.7?
[19:13] <ssitter> I guess all that is need is to move the focus away from the datetimepicker before saving the event/task
[19:14] <ulf> ssitter: would you mind to make a comment into the bug, so that mickey can see your suggestion
[19:15] <ulf> mschroeder: 0.7? seems to be fine
[19:15] <mschroeder> ok
[19:15] <mschroeder> Bug 386479
[19:16] <firebot> mschroeder: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=386479 nor, --, ---, giermann@funke.de, ASSI, Switch to Calendar mode don't work properly using buttons, Calendar menu or keyboard shortcut
[19:17] <mschroeder> I suppose this is more than one issue.
[19:19] <mschroeder> old toolbarbuttons, ctrl+3 to switch to calendar mode and an unnecessary Calendar menu in Mail mode.
[19:20] <ssitter> I would expect that all this commands call the same function/method to view the calendar.
[19:20] <ulf> mschroeder: right but as I understand comment #7 "Why don't we offer functions for the toolbar, that are still accessible through
[19:20] <ulf> the menu?"
[19:20] <ulf> This is exactly what Berend is currently preparing
[19:20] <ssitter> this function/method should be changed to switch to calendar mode too
[19:21] <ulf> ssitter: I think this is the approach mickey also suggested
[19:22] <mschroeder> I don't think Sven will have a patch in time.
[19:23] <ulf> mschroeder: one the other hand I find it hard to believe that chrisJ will accept the current state for 0.7
[19:23] <mschroeder> or maybe after mickey answers him in the bug Sven will provide a complete version of his patch.
[19:24] <ctalbert> We might just take a "wait and see" approach on this one for now.
[19:24] <ulf> at least my understanding is that the feature is not cmpletely satisfying
[19:24] <ctalbert> s/just take/just have to take
[19:24] <ulf> ctalbert: right
[19:24] <mschroeder> ctalbert: Do you think that's sufficient?
[19:24] <ssitter> yeah, most of the stuff in comment #7belong to different bugs
[19:26] <ctalbert> I agree with ssitter.  We should file follow-on bugs for those (better yet, invite Sven to do that).  But Sven has been pretty responsive, so if he gets some direction from Mickey on what to do for this particular bug, then he will probably supply us with a patch.
[19:26] <ssitter> maybe we also want to relnote that users should do a "Restore Defaults" on the toolbar to get the "best results" out of 0.7
[19:26] * mschroeder agrees with ctalbert :)
[19:27] <ctalbert> ssitter, not a bad idea
[19:28] <ctalbert> We need to talk to Chris-j about what he is expected as far as UI quality in 0.7 too.
[19:28] <mschroeder> ssitter: good idea
[19:28] <ctalbert> Perhaps we can get by with the "basic new UI works and is usable", and then do some of this UI polish in the 0.7 -> 0.9 timeframe
[19:29] <ctalbert> But, that is a decision that we should be involved in as well as chris-j and daniel.  Maybe next week's status call would be a good place to discuss that.
[19:29] * mschroeder agrees
[19:30] * mschroeder has to leave now. Time is up.