18:41:17 <colonelqubit> #startmeeting
18:41:17 <IZBot> Meeting started Wed Dec  3 18:41:17 2014 UTC.  The chair is colonelqubit. Plugin info at http://wiki.debian.org/MeetBot.
18:41:17 <IZBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:42:04 <colonelqubit> I'll start w/stats. UNCONFIRMED steady at 628
18:42:25 <colonelqubit> needAdvice: steady at 18
18:43:27 <colonelqubit> regressions in 4.4, 4.3, and 4.2 are: 37, 77, and 101
18:43:31 <colonelqubit> All down slightly
18:44:11 <colonelqubit> All Bibisected Bugs: 185
18:44:56 <colonelqubit> Bibisected regressions: 188
18:45:32 <colonelqubit> Still have a few bugs (18) in preBibisect, waiting for action
18:46:17 <Liongold> back
18:46:20 <colonelqubit> cool
18:46:27 <colonelqubit> Liongold: I just went over some stats in the meantime
18:46:38 <colonelqubit> tl;dr -- most things are holding steady
18:47:22 <Liongold> colonelqubit: ok
18:47:25 <colonelqubit> Liongold: what've you been up to?
18:47:38 <Liongold> colonelqubit: Nothing much really.
18:48:01 <colonelqubit> Any bugs in particular that need to be addressed?
18:48:14 <colonelqubit> beluga_, mjayfrancis, etc..: feel free to chime-in
18:48:32 <colonelqubit> jphilipz_meeting is otherwise disposed, I assume :P
18:49:03 <beluga_> colonelqubit: well there are general policy things, like are failing unit tests banned from the tracker like moggi insists
18:49:36 <beluga_> do we consider WFM bugs bibisect material..
18:50:08 <colonelqubit> Let's answer those one at a time :-)
18:50:08 <beluga_> should there be a backportRequest:4.3 whiteboard like we discussed earlier
18:50:14 <colonelqubit> Sure, sure
18:51:04 <colonelqubit> beluga_: what's the summary about failing unit tests?
18:51:20 <beluga_> moggi closed https://bugs.freedesktop.org/show_bug.cgi?id=82702 and https://bugs.freedesktop.org/show_bug.cgi?id=83241 as invalid, but mjayfrancis disagrees with the action
18:51:22 <IZBot> bug 83241: LibreOffice-filters and storage normal/medium RESOLVED INVALID Failing unit test sw_ooxmlimport building master on OSX 10.9.4 / Xcode 5.1.1
18:52:02 <beluga_> I remember a report where Joel closed it but then reverted closing after getting advice from devs that unit test problems are welcome on the tracker
18:52:45 <beluga_> I have a category for those reports: https://wiki.documentfoundation.org/QA/BugTriage/HardBugs#Compiling.2Funit_tests
18:53:32 <colonelqubit> From a technical perspective, I don't have a problem with these types of bugs being reported on bugzilla
18:54:18 <colonelqubit> I can understand that the devs want to hash out these problems on the mailing list
18:55:31 <colonelqubit> For some general build problems, a bug report seems clumsy and perhaps unwarranted, however if a change in the code did cause a unit test to break, then a bug report seems like the best mechanism to both report and keep track of the progress of a fix
18:56:37 <colonelqubit> At the end of the day, if devs don't want to respond to build-related bugs in the tracker, then there's no good reason to put them there
18:56:42 <moggi> colonelqubit: we want all build problems on the mailing list
18:56:56 <moggi> nobody tracks bugzilla for these kind of bugs
18:57:05 <colonelqubit> moggi: is there a mechanism to ensure that problems reported are followed-up and fixed?
18:57:14 <colonelqubit> (a bug tracker is very good at doing that)
18:57:33 <moggi> how that? if nobody checks bugzilla it means it is just noise
18:57:54 <colonelqubit> moggi: if a problem is reported on bugzilla, it remains until someone takes action to resolve/close it
18:58:04 <moggi> normally if a build problem is more than 3 days old it is either fixed or specific to the users setup
18:58:11 <colonelqubit> if a problem is reported on the mailing list, it can just be ignored and fall away into the archives
18:58:21 <moggi> in both cases the dev mailing list where many people look at these problems are a better idea
18:58:27 * colonelqubit nods
18:59:13 <colonelqubit> Okay, so for the time being, let's say that all build/unit-test related issues should be reported to the mailing list
18:59:20 <colonelqubit> beluga_: you good with that?
18:59:26 <moggi> normally most messages on the list get an answer, otherwise just bring the topic up again after 2 or 3 days if it is still an issue
18:59:32 <beluga_> colonelqubit: sure
18:59:52 <colonelqubit> moggi: Well that's basically my point: The onus of the fix is on the reporter, not on the devs
19:01:52 <colonelqubit> #agreed All issues/bugs re: building LibreOffice and unit tests will be marked 'RESOLVED NOTOURBUG' and reporters will be pointed to the dev mailing list
19:02:08 <colonelqubit> #action Robinson will make a note about that on the BugReport wiki page
19:02:28 <beluga_> yep I'll remove the category from my hard bugs list
19:03:08 <colonelqubit> Let's see Beluga #2) Should we bibisect WFM bugs?
19:03:32 <beluga_> examples https://bugs.freedesktop.org/show_bug.cgi?id=82092 https://bugs.freedesktop.org/show_bug.cgi?id=74300
19:03:34 <IZBot> bug 74300: LibreOffice-Database normal/medium UNCONFIRMED Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
19:03:42 <colonelqubit> Personally I'd suggest that people spend their time bibisecting the most important regressions, but that's just my practical side :-)
19:04:02 <beluga_> to quote robert from 74300: "How could you set this to "RESOLVED" and "WORKSFORME"? It seems to be a bug in 4.3.3.2 - and 4.3 will have some more bugfixes."
19:04:29 <beluga_> so robert's view would require a bibisect, right?
19:04:41 * colonelqubit was reading 82092
19:05:14 <colonelqubit> beluga_: but you're also touching on the question of marking a bug WFM if master is fixed but a branch might not be...
19:05:23 <colonelqubit> Let's talk about bibisecting WFM bugs first
19:05:40 <colonelqubit> Here's the deal: Bibisecting is only valuable if someone can reproduce the bug, right?
19:05:40 <beluga_> sure the one leads to the other :)
19:06:05 <arnaud_versini> colonelqubit: I can't see how to bisect a bug I can't reproduce !
19:06:18 <colonelqubit> So even if we resolve a bug as WFM, if someone wants to bibisect the problem to determine which commit introduced it, more power to him
19:06:39 <arnaud_versini> yes
19:06:54 <colonelqubit> arnaud_versini: oh, certainly! In this kind of case, OP or someone else who sees the same problem will have to do that work for us
19:07:15 <arnaud_versini> But we should verify that he can reproduce the bug, just not try to bibisect
19:07:54 <colonelqubit> As an example, I think that jphilipz_meeting has a couple bugs that only appear on one of his machines. Bibisecting might turn up something valuable there that is only visible with particular hardware configs
19:08:02 <arnaud_versini> To be sure he's just wasing it's time
19:08:14 * colonelqubit nods
19:08:25 <arnaud_versini> colonelqubit: We can have the same logic if it's profile related
19:08:27 <colonelqubit> I agree that we should be very clear about all of this
19:09:08 <colonelqubit> beluga_: tell the reporter that we can't reproduce it, so it's unlikely that we'll be able to fix it, *however* if they want to go through the process of bibisecting the issue, that might lead to some information that can be actionable
19:10:05 <beluga_> colonelqubit: ok in the future I will do that and I will now comment to robert about this and put 74300 back to WFM
19:10:07 <colonelqubit> It's basically a long shot, but it is something they can do
19:10:37 <colonelqubit> beluga_: Okay, now for #3) tagging desired backports
19:11:31 <arnaud_versini> colonelqubit: The problem is it's not sure that bibisect repo have the same issue
19:12:08 <colonelqubit> arnaud_versini: oh, you're saying that it's possible that the reporter can't reproduce w/bibisect?
19:12:12 <colonelqubit> (bibisect repo)
19:12:26 <arnaud_versini> colonelqubit: Yes, sorry I'm too late for this subject
19:12:46 <colonelqubit> no worries -- it's a good question
19:12:49 <beluga_> arnaud_versini: but in the cases where there are more than one confirmations it would be possible
19:12:58 <arnaud_versini> colonelqubit: Not the same options for compilin, not sure if it use the same profile
19:13:23 <colonelqubit> Here's what I'd say: Using bibisect is a long-shot. If you can't reproduce using the bibisect repositories, there's not much more you can do aside from building LibreOffice yourself (e.g. using git-bisect)
19:13:39 <arnaud_versini> beluga_: i'm just ssaying that if he have the issue with one package, I can't be sure that bibisect have the same
19:13:50 <colonelqubit> It's all a question of how much effort one is willing to invest :-)
19:14:26 <arnaud_versini> colonelqubit: even with your recommendation, should be with same compiling options
19:14:38 <arnaud_versini> As the OS package
19:15:02 <colonelqubit> ??
19:15:28 <colonelqubit> If someone is willing to recompile several versions of LibreOffice to track down a bug, IMHO they can use whatever switches and options they like
19:15:46 <arnaud_versini> colonelqubit: Sorry, my mistake, I say that building it yoursaelf is not sure also
19:15:49 <colonelqubit> The hope here is that they'll eventually find a single commit that changed something, and that's interesting
19:16:05 <arnaud_versini> colonelqubit: I agree :-)
19:16:32 <colonelqubit> even after all of that, they need to find a developer willing to investigate the suspect commit
19:17:23 <IZBot> News from fdonew: [Bug 86981] make non-printing characters a different, lighter colour <https://bugs.freedesktop.org/show_bug.cgi?id=86981> || [Bug 86983] PRINTING: Portrait mode must be set in print dialog and printer preferences to work <https://bugs.freedesktop.org/show_bug.cgi?id=86983>
19:17:35 <colonelqubit> Okay, let's move on to Beluga's #3)
19:17:41 <colonelqubit> Here are the notes I took: https://wiki.documentfoundation.org/QA/Meetings/2014/December_03#backport
19:18:45 <colonelqubit> The idea is that if a bug is resolved WORKSFORME, someone might still request a backport
19:18:56 <colonelqubit> (to an active branch)
19:19:32 <arnaud_versini> colonelqubit: The bug should marked as RESOLVED ?
19:19:57 <colonelqubit> I suggested whiteboard tags backportRequest:4.3 and backportDenied:4.3 -- for the requester and for a developer who has a good reason to not backport
19:20:41 <colonelqubit> arnaud_versini: correct, so if there's a bug that's fixed on master/Fresh, but is present on Fresh/Still, one could request a backport
19:21:27 <colonelqubit> By default, I believe a lot of work is backported to Fresh, and (to a limited extent) also added to Still
19:23:12 <colonelqubit> To ensure that we don't waste dev time, before tagging backportRequest, one should grab a daily build of the branch and ensure that the bug has not been fixed
19:25:01 <colonelqubit> In some cases, we won't know which commit fixed a bug, so that might be an impediment to getting a fix
19:25:02 <arnaud_versini> colonelqubit: Perhaps we could have a backport machine to test the backport ?
19:25:24 <colonelqubit> arnaud_versini: hmm? how would that work?
19:27:00 <arnaud_versini> colonelqubit: Personally I'm always working on master, but if I have a machine, even shared with fresh and still, I can test myself the backport
19:27:22 <colonelqubit> arnaud_versini: well right now we have builders providing dailies of 4.2 and 4.3
19:27:47 <arnaud_versini> colonelqubit: Yes, but they don't test backports before it's commited
19:28:15 <colonelqubit> arnaud_versini: ah, okay -- you're saying that people don't test to make sure that the backported patch was successful
19:28:46 <colonelqubit> I think the daily builds of Still and Fresh would all users to perform that test
19:28:56 <colonelqubit> *would allow
19:28:58 <arnaud_versini> colonelqubit: No, just that qa team with this can test backport instead of asking
19:31:03 <colonelqubit> arnaud_versini: are you suggesting that QA run the backport step, build LibreOffice, and test to see if the backported commit(s) fixed the problem?
19:31:29 <arnaud_versini> colonelqubit: Why not ?
19:31:52 <colonelqubit> arnaud_versini: it's a cool idea, but I think that's a bit beyond our scope right now
19:32:01 <arnaud_versini> colonelqubit: If we have a way to do that with a simple way, could be better
19:32:10 <arnaud_versini> colonelqubit: Ok sorry
19:32:34 <colonelqubit> Sure, it's something I'd investigate in the future, but I'd suggest that we focus more on our current QA tasks
19:32:59 <arnaud_versini> Ok
19:33:00 <Liongold> colonelqubit: May I jump in for a sec on somethign else?
19:33:02 <colonelqubit> once we have our Bugtracker more under control, perhaps we can see about setting up more machines for tests like that
19:33:19 <colonelqubit> Liongold: one sec -- let's try to wrap up this bit first
19:33:26 <Liongold> colonelqubit: No prob
19:33:41 <colonelqubit> So what do people think about these whiteboard tags? Should we test them out?
19:34:17 <beluga_> colonelqubit: what about asking on the dev list?
19:34:33 <beluga_> I mean for opinion on this
19:34:33 <colonelqubit> moggi: do you think devs would pay attention to bugs that are marked with backport requests?
19:35:24 <colonelqubit> beluga_: yep, we can ask on dev list
19:35:49 <beluga_> I also have one thing after Liongold
19:36:28 <colonelqubit> Liongold: okay, you're up!
19:36:58 <Liongold> colonelqubit: Just small question: is the BSa working? If no, were there any tests to find the cuause?
19:37:17 <Liongold> My typing is horrible today.
19:37:22 <colonelqubit> Liongold: I believe BSA is still having problems.
19:37:52 <Liongold> colonelqubit: Amy more info about the cause?
19:38:13 <colonelqubit> Is ertai_NL online? I believe that clophhas given him access; we were planning to set up a 2nd VM to test the BSA against the local Bugzilla install as well
19:38:37 <colonelqubit> Liongold: the BSA broken when FDO upgraded Bugzilla
19:39:14 <moggi> colonelqubit: well, if you point to a specific commit that fixed it and the dev thinks it is reasonable we normally do it
19:39:37 <colonelqubit> moggi: Yep, in many cases I expect that we won't know which commit fixed a problem
19:39:56 <moggi> colonelqubit: if it is just: it is fixed in the next release, I want that bug also fixed in the other branch but don't know which commit fixed it we will most likely ignore it
19:40:23 <colonelqubit> moggi: Do you think it would be reasonable to track which branches are affected by a bug?  (e.g. FIX on master, FIX on 4.3, NEW on 4.2)
19:41:01 <Liongold> colonelqubit: Ok, thanks a lot. So most likely it is more admin task right?
19:41:28 <moggi> we do that already, if a bug has been fixed by a commit the bugzilla bot writes the branch that got the fix into the whiteboard line
19:41:45 <moggi> colonelqubit: all other bugs should be marked as duplicate or we don't know which commit fixed it
19:41:59 <colonelqubit> Liongold: yes, infrastructure issue -- I'll try to get you more information this week
19:42:04 <moggi> if we don't know it we can also not backport the fix
19:42:19 <Liongold> colonelqubit: Ok, thanks and sorry for disturbing.
19:43:13 <colonelqubit> moggi: sure. The issue we ran into is that if we mark a bug WFM because the problem isn't present on Master, there's no good mechanism to signal to the devs that the problem is outstanding on the Fresh or Still branches
19:45:40 <moggi> colonelqubit: as long as there is no commit that is know to fix the bug there is little chance some dev will debug it on an old branch
19:45:45 <moggi> unless it is really serious
19:45:50 * colonelqubit nods
19:45:56 <moggi> or a customer makes us to look at it
19:46:24 <colonelqubit> beluga_: you brought this one up, so what do you think?
19:46:42 <colonelqubit> For MABs, I agree with moggi: I think a customer or duplicate bug reports will push the issue into the light
19:47:16 <beluga_> colonelqubit: I would use the whiteboard tag, if devs scan them
19:47:29 <IZBot> News from fdonew: [Bug 86984] UI:Line Numbering. Include header or footer can't be checked and has no effect on counting. <https://bugs.freedesktop.org/show_bug.cgi?id=86984> || [Bug 86985] No auto-update on Windows. Please add a new auto-update and auto-install feature. <https://bugs.freedesktop.org/show_bug.cgi?id=86985>
19:47:34 <beluga_> or maybe even ping the dev that fixed it?
19:47:49 <colonelqubit> beluga_: Sure, if the bug has a fix associated
19:48:00 <colonelqubit> beluga_: What was the original bug report?
19:48:22 <beluga_> well I had this example #74300
19:48:24 <IZBot> LibreOffice-Database normal/medium UNCONFIRMED Base:Database "Position and Size" box does not paint - it displays what's beneath it instead https://bugs.libreoffice.org/show_bug.cgi?id=74300
19:49:08 * colonelqubit nods -- yep, that's the one
19:49:08 <beluga_> but that is maybe a bad example as it seems to be win-only
19:49:33 <colonelqubit> that's a good example, as we don't know which commit fixed the problem, so we don't have a dev to ask
19:50:28 <beluga_> yeah I mean bad in the sense that no hope for a bibisect result
19:51:25 <colonelqubit> So if that bug isn't bad enough to become a MAB, then it's probably not going to raise the attention of a dev
19:51:44 <colonelqubit> remember: This is a bug that's fixed on master, so it's very low priority for devs to address
19:53:17 * colonelqubit thinks
19:53:27 <colonelqubit> I don't have a good answer here --
19:54:37 <colonelqubit> I think the whiteboard tag is as good of a suggestion as any. We should be honest with users, so if they ask about when it'll be fixed, we can tell them that a developer will have to show some interest
19:57:00 <colonelqubit> I'm thinking that rather than a 'backportRequest' tag, perhaps we be more explicit about the bug still existing on the branch
19:57:24 <colonelqubit> so e.g. "openOnBranch:4.2" or perhaps "affectsBranch:4.2"
19:58:56 <colonelqubit> #action Robinson will draft some language about using the whiteboard to indicate if a bug is open on Fresh/Still branches
19:59:04 <colonelqubit> beluga_: okay, got anything else?
19:59:22 <beluga_> I have one thing from iplaw67: we need a foolproof way to decide, if an issue is a blocker, MAB or both
19:59:47 <colonelqubit> The devs continually say that "we don't have blockers"
20:00:02 <jumbo444> moggi: Hello Moggi. I catch your attention about fdo#83606 which require a push of d5a0926c2359a4f8bd48cbea5a9c034b87d6aeeb to 4.3 branch. Thanks :)
20:00:03 <IZBot> core - fix range input in chart data source dialog - http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5a0926c2359a4f8bd48cbea5a9c034b87d6aeeb
20:00:31 <colonelqubit> I agree that the names are unfortunate, but it's what FDO put in place
20:00:38 <beluga_> colonelqubit: remove blocker option in the self-hosted zilla :) ?
20:00:39 <colonelqubit> jumbo444: joining the meeting?
20:01:22 <colonelqubit> beluga_: Sure -- we just need to have some scale for ranking the relative importance/severity of bugs
20:02:23 <beluga_> colonelqubit: yep we had a little discussion about MSO files displaying with hidden information - is this considered data loss
20:02:27 <colonelqubit> Our eventual goal is to get rid of the MAB tracking bugs and just prioritize bugs directly
20:02:59 <beluga_> and data loss leads to critical according to the flowchart
20:03:01 <colonelqubit> In order for the devs to trust prioritization, we need more control over who can prioritize ---> (waiting on our own bugzilla)
20:03:47 <colonelqubit> beluga_: it sounds like we just need to update the flowchart
20:03:48 <beluga_> yep I did more and more priority tweaks in my "amok run" :)
20:04:13 <colonelqubit> Personally, I'd love to see more devs tweaking priority on bug reports
20:04:26 * colonelqubit isn't sure how much that happens right now, but I do believe a certain amount
20:05:02 <colonelqubit> beluga_: if the flowchart needs an update, can you take the lead on that?
20:05:17 <beluga_> colonelqubit: I can take the lead of nagging Joel
20:05:24 <colonelqubit> Sounds like a plan
20:05:36 <beluga_> it's genius, if I do say so
20:05:47 <jumbo444> colonelqubit: Hello. Just reading, and I've got an example about your topic. But not exactly the same pb, as in this case I could find the commit
20:06:00 <colonelqubit> #action Beluga will talk with Joel about updating the Bug Triage flowchart (re: severity/priority)
20:06:08 <colonelqubit> jumbo444: whatcha got?
20:07:05 * colonelqubit looks at the time
20:07:39 <colonelqubit> Okay, we're at the 1.5h mark, and we've had some great discussion, but I don't want to make this much longer
20:07:49 <colonelqubit> I've got two quick announcements
20:08:02 <colonelqubit> 1) Our next BugHunting Session is coming up in two weeks
20:08:39 <colonelqubit> https://wiki.documentfoundation.org/BugHunting_Session_4.4.0_RC1
20:09:33 <colonelqubit> It'll be Dec 19-21, so make sure to save some time that weekend to help beat on the RC1 and see what we can break :-)
20:10:06 <colonelqubit> 2) I'll be pushing-out updated bibisect repo for 4.4 shortly. More information on the mailing list
20:10:49 <colonelqubit> Anyone have anything else?
20:12:05 <colonelqubit> okie dokes. Thanks all for the great meeting!
20:12:11 <colonelqubit> Our next meeting will be Dec 17th @ the same time and place.
20:12:36 <colonelqubit> #endmeeting