13:26:28 #startmeeting 13:26:28 Meeting started Wed Oct 7 13:26:28 2015 UTC. The chair is colonelqubit. Plugin info at http://wiki.debian.org/MeetBot. 13:26:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:27:15 steve-_-1, beluga_, DennisRoczek, ahoneybun, CorNouws, dave_largo, jphilipz: meeting time 13:28:01 First off, a big thanks to CorNouws for pinging me about those references bugs 13:30:56 tdf#94804, tdf#94063 13:30:56 Crashers and data loss bugs are especially heinous, so please nudge them in my direction before the ESC each week 13:30:56 UNCONFIRMED bugs is up above 500 again (502). 13:30:57 Thoughts on how we can better-tackle the firehose of bug submissions we get each week? 13:30:58 LibreOffice-Writer critical/highest NEW EDITING References break when putting text behind them. https://bugs.documentfoundation.org/show_bug.cgi?id=94063 13:31:56 beluga_: Would it be helpful for us to have a specific time each week to tackle them? 13:31:59 colonelqubit: as previously stated: implement the bugzilla form as default for all incoming bugs (but that is waiting for BZ 5.x from what I understand). 13:32:56 colonelqubit: nothing else helps, but recruiting more people :) the majority of the reports is very easy to react to (either needinfo or triage) 13:33:13 beluga_: fair enough 13:33:25 steve-_-1: will that form prevent errors / ommissions? 13:34:22 CorNouws: it can help the user through the submission process 13:34:24 https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&format=guided 13:35:01 CorNouws: sure not, but it will hopefully decrease the dupe count if we do it right. 13:35:52 colonelqubit: steve-_-1, ah, ok, good 13:36:04 steve-_-1: Do you think that users will accurately be able to tell if their problem is the same as another one? 13:36:17 * CorNouws then we can't any longer count severity on duplicates ;) 13:36:19 dupes is a hard problem 13:36:31 I know that some devs have expressed concern about users claiming to have the same bug.. 13:37:21 colonelqubit: we'll have to see. but at least we should show step 1 (the option to have a glance at similar existing or top 100 of current bugs). ah, so that claiming is too easy and users just claim that without the proper research? 13:37:48 colonelqubit: i've submitted bugs which have been duplicates and i search to find duplicates on bugzilla and didnt find the one which was stated as the duplicate 13:38:14 alot of it comes down to a difference in wording 13:38:18 jphilipz: so you're saying the duplicate-finding mechanism could be improved? 13:38:23 * colonelqubit nods 13:38:45 I recently got told "Please search before reporting and confirming." #94718 but I'm not sure I would have found that dupe.. 13:38:47 LibreOffice-Writer normal/medium RESOLVED DUPLICATE (of 93986) Visio object in DOCX have incorrect font size, font face, and line width https://bugs.documentfoundation.org/show_bug.cgi?id=94718 13:38:49 LibreOffice-Writer normal/medium NEW FILEOPEN: fonts garbled in Visio object from DOCX https://bugs.documentfoundation.org/show_bug.cgi?id=93986 13:39:03 If I understood the "claim" argument correctly, it also applies to the current situation so not a valid argument against the form imo. 13:39:18 no one is argumenting against the guided form 13:39:35 colonelqubit: mentioned the dev input about the claim 13:39:45 not sure what they where intending to say then 13:40:04 beluga_: i've been told that as well :D 13:40:18 steve-_-1: people me-too'ing on a bug report, when their issue was (probably) something different 13:40:46 yes, but that is an argument for / against what exactly? 13:40:58 Oh, for my ideal bug tracker -- each users's report should be an object, and a dev should be able to combine or separate particular users reports that are related or separate 13:41:16 a number of times, i got stopped from making a duplicate by typing in the summary 13:41:31 * beluga_ would like to have an argument (à la Monty Python) 13:41:39 dupes are very hard. there are several things that result: QA should probably start improving titles so bugs can be better found (similar to adding the comment # to the headline if a bug gets too messy) 13:42:08 steve-_-1: yeah, that helps, but I wish we didn't have to use hacks such as that 13:42:47 you also have users running older versions of LO (e.g. 5.0.0) and the bugfix is already in on the current version (5.0.1), so dupes will continue to come in 13:43:14 jphilipz: sure; there's always a potential for churn 13:43:29 As beluga_ said: The key is more recruitment 13:43:30 yep, I am not sure any casual user is still able to follow the release structure of LO though 13:43:54 yep, form aside, in the end, it's just takling the bugs one after one and getting them triaged. 13:44:01 once automated updates come through, i think it would be better 13:44:16 I have not had time for deep triaging because of the large volume of reports 13:44:34 #action Design better plan for recruiting and retaining volunteers for QA Team (Robinson) 13:44:37 and that resulted to Cor writing this: http://lists.freedesktop.org/archives/libreoffice-qa/2015-October/009090.html 13:46:03 Okay, let's take a look at our pending topics 13:46:05 #topic Pending Topics 13:46:21 colonelqubit: on a separate note, does QA want to receive the minutes from the design meetings? 13:46:35 beluga_: not only that issue. I had the idea earlier too. 13:47:07 colonelqubit: ^^^ /009090.html ? 13:47:09 jphilipz: I don't have a strong aversion to it, but perhaps people can just subscribe to projects list? 13:47:36 * CorNouws looks at QA list ~once a week .. :\ 13:47:52 CorNouws: let's return to that after we go over the pending topics from last time 13:48:18 Multimedia: Any update on those image tests? 13:48:24 colonelqubit: sorry that I did not know /repsect the order ...! 13:48:33 colonelqubit: decisions made in design will likely affect bugs QA will triage, so maybe they'd like to be kept in the loop 13:48:40 CorNouws: no worry -- > you can take a quick look here: https://wiki.documentfoundation.org/QA/Meetings/2015/October_07 13:49:06 colonelqubit: thanks for the link, i didnt know where the stuff was held 13:49:17 jphilipz: then yes, please do cc the qa list 13:49:33 :-) 13:49:47 I have one thing this week if it's OK 13:49:55 dave_largo: yep, and you had something from last time 13:50:04 https://bugs.documentfoundation.org/show_bug.cgi?id=94138 13:50:05 bug 94138: LibreOffice-Printing and PDF export normal/medium NEW Form Control Text Boxes Print And Export To PDF Incorrectly 13:50:20 This bug is killing us....can we look at maybe rolling back this commit? 13:50:42 dave_largo: sure; let's take a look at the new stuff after the old stuff 13:50:53 Ok :) 13:50:58 So...quickly: Multimedia: No update on the image tests 13:51:10 I'll make a note about jumping in there 13:51:41 mjayfrancis: you about? 13:51:56 "ACTION: File an enhancement request for a script that normalizes and diffs two user profiles " 13:52:06 Anyone know if that got filed? 13:52:31 Okay, punting for next time 13:52:37 dave_largo: you're up! 13:52:44 "ACTION: Track down Armin's SVG patch and get some stats re: how much faster SVG was in old versions (dave_largo)" 13:53:24 Ok, we kind of got that as the meeting was happening last week. It was a huge slowdown with SVGs after that patch a few years ago. 13:53:50 dave_largo: So what's next there? 13:53:50 We know the patch that slowed it down, I would have no way to fix it unfortunately. 13:54:14 dave_largo: do we have a bug filed and tagged as 'perf' ? 13:54:17 It's the same thing I think that makes the help > about screen so slow. 13:54:36 Let me find the bug, and mark it perf, just wrote a note. 13:54:38 ah yes, okay, so we do have that noted, and IIRC I did bring it up in ESC 13:55:17 I can look on my server and see if I have old versions prior to the patch. 13:55:47 there are many bug reports on slowness of SVG and images around the 3.5 or so time 13:56:09 yup, they are all from that patch I think 13:56:30 dave_largo: wrt 94138: my comment #6 is in contradiction with your comment #4... ideas? 13:56:35 dave_largo: the better we can characterize the problem and point out the patch, the more clout that'll give us in the ESC 13:57:15 dave_largo: pls report in the issue ;) 13:57:16 of course, some bugs are gordion knots that are hard to unravel 13:58:11 Armin emailed me at one point and was talking about X hops and that SVGs with lots of channels are slow. 13:59:04 dave_largo: okay, I'm going to mark that ACTION item as DONE. We can continue to nudge about the problem :-) 13:59:27 Sounds good.....our NX technology has made it work slightly better, but it's still slow. 13:59:33 over remote X, it's just painful 13:59:37 * colonelqubit nods 13:59:41 Next pending: "ACTION: Review MABs, wiki pages and other resources dependent on them," 13:59:51 the svg commit is likely in this comment - https://bugs.documentfoundation.org/show_bug.cgi?id=82214#c14 13:59:53 bug 82214: LibreOffice-graphics stack normal/medium NEW SVG image causes UI freeze when scrolling and slow export of PDF 13:59:56 I looked briefly at these; still need updates for the wiki pages 14:00:35 beluga_: did you get a chance to review what was sitting on mab4.3 and mab4.4? 14:01:19 colonelqubit: I didn't know of such a task 14:01:37 beluga_: I thought you mentioned reviewing some mabs to make sure they were all categorized with priority:highest 14:01:48 perhaps you and I can tag-team that this week 14:01:54 I'll leave that action item open for now 14:01:55 * beluga_ Review MABs, wiki pages and other resources dependent on them, and determine workload to switch over to using Priority:highest (Robinson or Other) 14:02:02 https://wiki.documentfoundation.org/QA/Meetings/2015/September_16 14:03:09 beluga_: what about it? 14:03:34 yeah just that it was not for me and not by me 14:03:52 but I guess I will make a note to check them out 14:04:18 beluga_: oh yes; I thought that you'd made a comment to me in IRC about reviewing MABs -- it might have been about checking them rather than re-prioritizing 14:04:37 In any case, that's it for old stuff 14:04:43 #topic New Topics 14:04:59 We've already discussed UNCONFIRMED bugs 14:05:08 raal1: hiya -- just having QA meeting 14:05:19 raal1: (and I'll mention win32-bibisect later) 14:05:32 okay, so who was first here -- dave_largo, you had a bug? 14:05:59 CorNouws: you had something as well 14:06:01 the bug is at noted: 14:06:05 https://bugs.documentfoundation.org/show_bug.cgi?id=94138 14:06:07 bug 94138: LibreOffice-Printing and PDF export normal/medium NEW Form Control Text Boxes Print And Export To PDF Incorrectly 14:06:20 We have hundreds of forms with those controls in them, and we cannot print them. 14:06:48 I can't really move many more people to LO 5 because of this printing issue sadly. 14:06:52 http://lists.freedesktop.org/archives/libreoffice-qa/2015-October/009090.html 14:07:07 colonelqubit: sorry, out of time, need to work :-( 14:07:14 raal1: no worries 14:07:34 dave_largo: I would abstain from moving to 5.0 for some other reasons too ;) 14:07:47 Haha...actually 5 is working really well for us. 14:08:07 There are always bugs in LO, but the import filters in 5.0 are much better for DOCX 14:08:08 colonelqubit: but about winbibisect I wrote with norbert, I'll test more, probably my fault. 14:08:12 dave_largo: old hardware is going to have crashes with object filling 14:08:33 CorNouws: +1 to your request on triaging 14:08:38 (small note: I checked 4.4 mabs and set to highest, except for this, which Adolfo set to high from highest #88276 ) 14:08:40 LibreOffice-Draw major/high NEW Please add UI for new LO 4.4. feature "Text Background Color in Draw" https://bugs.documentfoundation.org/show_bug.cgi?id=88276 14:08:42 raal1: ah, good. I have a note here to touch base w/him, but if you're good for now, I'lll consider it resolved 14:09:20 All of our users are on the same hardware, big servers. LO doesn't run on workstations at all. 14:09:56 beluga_: you tested in win7 and had what result? 14:10:59 colonelqubit: tested what? 14:11:13 the bug in question: https://bugs.documentfoundation.org/show_bug.cgi?id=94138 14:11:15 bug 94138: LibreOffice-Printing and PDF export normal/medium NEW Form Control Text Boxes Print And Export To PDF Incorrectly 14:11:38 colonelqubit: I had this result https://bugs.documentfoundation.org/show_bug.cgi?id=94138#c5 14:11:39 bug 94138: LibreOffice-Printing and PDF export normal/medium NEW Form Control Text Boxes Print And Export To PDF Incorrectly 14:11:50 Possibly there are different results with different printers too. 14:11:59 We have enterprise HP laser printers. 14:13:08 okay -- and it's been isolated to how large a commit range? 14:13:16 colonelqubit: ok I also checked and corrected the 4.3 mab priorities now 14:13:22 beluga_: thanks 14:13:46 colonelqubit: mjayfrancis told me its a set of commits that quickee did 14:13:48 dave_largo: we also have a HP printer that cost like 3000 euros 14:14:35 laserjet 700 color mfp m775 14:14:59 the new multi-function printers work great 14:15:53 dave_largo: can you chat w/ mjayfrancis for next week, and see if you cna figure out the smallest commit range? Or maybe quickee can give insight? 14:16:08 sure that sounds great! 14:16:11 dave_largo: I have no idea of the size of your city, but did you consider to look for a certified developer? Works fastest in may cases.. 14:16:31 We have someone that we hire to make LO changed from time to time. 14:16:36 * CorNouws s/may/many 14:16:48 We are going to fund adding the ability to insert Youtube videos 14:16:56 dave_largo: good :) 14:17:20 yep, I'm sure a bunch of people would like to see that! 14:17:51 We will fund the part to create a thumbnail of the video and then when you click on it, hand it to Firefox 14:17:59 Baby steps, but still a great feature. 14:18:25 Okay, CorNouws, let's take a look at your item: "Need keyword for issues that are New but still must be triaged.." 14:18:32 http://lists.freedesktop.org/archives/libreoffice-qa/2015-October/009090.html 14:19:45 CorNouws: So is the issue that important bugs are reproduced, but then aren't prioritized ? 14:21:53 in the time it takes to write that whiteboard, I would just prioritize/severitize 14:22:18 regression testing would take more time, but it won't improve with a whiteboard, if we don't have enough hands 14:22:19 colonelqubit: I'd more think about further testing/narrowing the issue 14:22:33 sophi: ah, okay 14:23:02 colonelqubit: or bisecting and so on that the reviewer would not have time to do on it 14:23:14 I think I mostly agree with beluga_ here. I understand that some new QA folks might be hesitant about triage, but we mostly do need people to jump in 14:23:22 colonelqubit: so it's more about fully documenting the bug 14:23:25 * colonelqubit nods 14:23:59 sophi: So in the case of better-describing/documenting the bug, perhaps we just need more descriptive ways to categorize the bug 14:24:43 colonelqubit: I don't think so, it's just the time to investigate that is not spent on it 14:24:53 * colonelqubit hmms 14:25:19 As we mentioned earlier, one of our biggest challenges is finding man-hours for triage 14:25:24 colonelqubit: sometimes you can confirm a bug, but need further researches to isolate it 14:25:41 yes, three things :) 14:26:06 true; I think that it can be challenging for QA to identify the highest-priority tasks and under-documented bugs and work on those 14:26:08 i always do testing of previous versions to confirm if its a regression or not, but not sure if others do, so maybe a keyword for when a person confirms but doesnt check if its a regression or not 14:26:14 a. good summary, b. priritizing, c. if needed add regression & bibisectrequest 14:27:02 jphilipz: one keyword for IamToBusyCanSomeoneElsePleaseFinishTriagingAndMore would be enought maybe :) 14:27:08 * colonelqubit laughs 14:27:12 How often do we have non-QA folks confirm (and set to NEW) bugs? 14:27:16 CorNouws: lol 14:27:20 we've already some keywords or how do we call it.. 14:28:02 colonelqubit: just a bit offtopic what is about redmine#1228 14:28:03 HTTP Error 401: Unauthorized - please visit the URL yourself: https://redmine.documentfoundation.org/issues/1228 14:28:03 not all QA folks have all versions installed on their system, so they wont do regression testing 14:28:06 colonelqubit: I sometimes do inclomplete triage too and then write it in a comment .. had to find for others 14:28:27 s/had/hard 14:28:45 DennisRoczek: ping me after the meeting 14:29:07 CorNouws: yes, using a keyword or tag in the Whiteboard is definitely preferable to anything in a comment 14:29:42 * CorNouws if I get paid € 10,- for every incomplete triaged bug, that will make me a nice skying vacation :) 14:29:52 I see two possible ideas here: 14:30:07 1) We ask QA to do all the steps when attacking a new bug 14:30:20 Up-front triage takes a little longer, but things are done fully 14:30:39 2) we pay QA for triaging 14:30:48 2) We set up the bug fields so that they're null/invalid until someone explicitly sets them 14:30:57 beluga_: or that :P 14:31:01 beluga_: defintely 14:31:42 beluga_: problem always is to keep a nice cooperation between voluntary and (partly) paid tasks & work 14:31:59 no strong ideas in this area yet, by the way. Didn't think about it. 14:32:14 3) qa outsources triaging to 3rd world country remote workers 14:32:20 colonelqubit: why makes things complicated, just a keyword like NeedFurtherWork or something like that would do, why preventing people from contributing if they are short on time 14:32:34 sophi: +1 14:32:45 Maybe think more in the direction of "projects": TDF tenders for someone going to sort, clean up and clarify all xxx-related bugs 14:32:47 or so 14:33:08 sophi: +1 from me too 14:33:12 sophi: The issue with a single keyword or whiteboard tag is that it doesn't describe what triaging work has been done so far 14:33:37 colonelqubit: correct, but it is at least a start 14:33:41 colonelqubit: the first work will be documented in the comments 14:33:46 NeedsRegressionTesting, NeedsPrioritizing 14:34:06 jphilipz: we could dump-in those tags automatically, and have QA clear them when each piece is done 14:34:18 colonelqubit: +1 14:34:26 colonelqubit: each time we touch an issue, we document what we have and the changes to the state of the issue 14:34:41 a little bit extreme, but it has the benefit of happening every time 14:36:05 the alternative is to do what the bibisect people do, add keyword onces its done (e.g. bibisected) 14:36:14 beluga_: thoughts on auto-adding tags? 14:36:49 jphilipz: yep -- although there is the initial rub of figuring out which NEW bugs are regressions 14:37:03 would suggest it be in keywords and not whiteboard, so people dont have to memorize the spelling 14:37:20 jphilipz: I would prefer having those keywords/tags in place from the beginning. Work done: remove. (Or checkboxes... done: uncheck..) 14:37:43 jphilipz: Right, as CorNouws says, they'd be automatically added whenever a bug is create 14:37:44 d 14:38:25 I guess auto adding is ok 14:38:26 My suggestion would be to put them in the Whiteboard, as it's less invasive than the Keywords 14:38:46 I think it's a plausible idea for us to test out 14:40:00 if its auto added, then whiteboard is fine 14:40:04 #action Formulate patch proposal to put 'needsPrioritizing', 'needsRegressionTesting', etc.. tags into Whiteboard (Robinson) 14:40:19 I'll take a crack at it, then we can test it out on the VM 14:40:26 (the bugzilla-test VM) 14:40:40 one more needsCorNouwsSealOfApproval 14:41:25 jphilipz: yeah, most important one :D Thanks, I nearly had forgotten that ;) 14:41:38 I'll send an email out with the proposed needs* tags to include 14:41:56 Okay, any other topics for us to discuss? 14:42:32 the disabling of the importance fields? 14:43:04 jphilipz: ah yes, I was saving that for the end :-) 14:43:05 who designs the Cor-seal? 14:43:18 action for the design team 14:43:29 gamification badge 14:43:48 The Lord Cor of course :D 14:43:50 gamification could honestly work out really well for us in getting new volunteers 14:44:12 especially with the coveted Cor-badge :-) 14:44:28 Okay, let's talk about the Importance fields 14:45:11 Big thanks to everyone for testing the latest patch on the test VM. I'm pushing the changes right after this meeting, so if you see something explode in Bugzilla, please let me know! 14:45:23 The latest behavior is as follows: 14:45:29 Admins: Get to do anything 14:45:49 Contributors (group): Change Priority, Change Severity to anything (but blocker) 14:46:07 Everyone else: Change Severity to enhancement up to Normal 14:46:26 One proposal is to just remove general access to the Severity field 14:46:49 yeah it seems floeff wanted that in the redmine comment 14:48:00 wanted only 'contributors' to have access ot the Severity field? 14:48:25 colonelqubit: to just remove general access to the Severity field 14:48:30 * colonelqubit nods 14:48:52 Status quo is that Priority/Importance is reflected in the patch and deployed to production, but Severity isn't reflected, which needs doing. https://redmine.documentfoundation.org/issues/1070#note-15 14:48:53 redmine: »Bugzilla importance field patch« in Infrastructure (Task for Robinson Tryon) [In Progress] 14:49:37 IIRC, the goal was to prevent users from Prioritizing their bugs too high 14:49:56 News from tdfnew: [Bug 94860] Fontsize changes on print  || [Bug 94859] Outline numbering can't start with zero (0) 14:50:01 as a QA member, I would be interested in testing the limited access.. so normal is the highest a regular user can set it 14:50:29 the theory is that we might still see edit wars, but I doubt it 14:50:34 beluga_: I'm hesitant to restrict access to, say, marking a bug as 'enhancement' 14:50:39 at least they will be few and far between 14:50:45 beluga_: right, and that's the current behavior on this patch 14:50:57 i've seen joel get into edit wars about people changing the importance 14:51:03 Sure, definitely 14:51:09 yes.. as I opened the redmine ticket, I would be ready to close is as done 14:51:37 My suggestion is still that we go with the current patch (behavior as mentioned above) and see if we still have edit wars 14:51:37 sure I've had my edit wars, but mostly about major and critical 14:52:01 well, actual wars are very rare 14:52:11 as users dont know about the importance tree, why let them edit stuff they shouldnt have control over 14:52:36 jphilipz: if we don't give them control, then all of their bugs will be 'normal' 14:52:39 people mistakenly edit version as well 14:52:47 jphilipz: because we get lower severity assessments for free? + enhancements 14:52:49 they can't mark a bug as an enhancement, etc. 14:53:07 jphilipz: yeah, the version field is a constant pain 14:53:22 my suggestion is let them set normal and enhancement on submission only 14:53:31 that's another story --> especially as what's more relevant for us is the *set* of versions in which we can reproduce the bug 14:53:46 jphilipz: woudl they be locked-in to those decisions after submission? 14:54:10 colonelqubit: QA has to triage and set it to where it should be 14:54:12 * colonelqubit would definitely like to be more liberal about including users in the 'contributors' group 14:54:36 Making a distinction between users and triagers has benefits and detractions 14:54:38 how many stuff which wasnt set to enhancement did you set to enhancement colonelqubit and send to ux-advise 14:54:52 users dont pay attention to more than summary and description and likely component 14:55:10 jphilipz: that's a fair point 14:55:23 jphilipz: not many, users generally know when the report is an enh. 14:55:24 they dont do testing of older versions 14:55:48 I would argue that most users don't intentionally change the fields to make our job difficult 14:55:54 it's mostly that they don't know any better 14:56:05 so dont let them touch stuff they dont know about 14:56:39 I'm fine with that, as long as we make sure to liberally hand-out elevated privs for anyone who wants them 14:56:47 onboard, onboard, onboard people 14:56:57 BTW the page for the next BH session is set https://wiki.documentfoundation.org/BugHunting_Session_5.1.0.0 14:57:04 thanks, sophi :-) 14:57:05 anyone who joins QA should be given the privs 14:57:16 colonelqubit: you're welcome :) 14:57:31 jphilipz: right, what I'm saying is that currently we don't have to be awake/around to let them get involved 14:57:55 if we move to a more restricted model, we then need to be more vigilant to onboard them 14:59:11 I suggest that we revisit again in a week, and take a look at all bugs filed from later today (after the latest patch is in place) until then 14:59:53 In the meantime, please: 14:59:55 bye - running for a meeting now 14:59:58 1) Welcome new contributors! 15:00:17 2) Ask them if they'd like to contribute --> then add them to the 'contributors' group 15:00:25 (I'm going to grant all of you privs to do that) 15:00:34 so no excuses! ;-) 15:00:46 3) Follow-up with them and see if they have any more q's 15:01:01 Sounds good? 15:01:17 we should make a simple one page of things new QA should be aware of 15:01:40 so we can point them to it and they read it and learn more 15:01:46 #action Make a simple page of things new QA should be aware of (jphilipz) 15:01:47 done ;-) 15:02:14 like i'd know what should be on that page :D 15:02:27 you are a gennnnnius 15:02:33 * colonelqubit is sure you can figure it out 15:02:47 okay, guys and gals, big thanks for the great meeting 15:03:21 Some of us have Action items -- please take a look at them between now and next week. Meeting will be @ same time and same place 15:03:33 sophi: when's the next BugHunting Session? 15:03:55 colonelqubit: October 30th to November 1st 15:04:06 Halloween! 15:04:20 colonelqubit: will be announced this week 15:04:36 Dress up like your favorite regression or data-loss bug and you could win a prize! 15:04:56 Thanks, all! 15:05:17 #endmeeting