Open Source Meeting/2009-07-02

From Second Life Wiki
Jump to: navigation, search

Open source meeting - Thursday, 2pm PT.

Teleport to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring large or contentious items up on SLDev before or concurrently with adding them as agenda items.

Agenda

2009-07-02

  • Your item here
  • Candidates for inclusion in Snowglobe:
    • VWR-9287 Building hotkeys to select next/previous prim in a link set (already in maint-viewer-15)
    • VWR-12984 Water flickers and disappears in patches --Thickbrick

Default agenda (after agenda above):


Transcript

  • [14:00] xstorm Radek: OMG!! its Rob
  • [14:00] Rob Linden: hi folks
  • [14:00] Morgaine Dinova: Hiya Rob!
  • [14:01] Morgaine Dinova: xstorm: just ignore them
  • [14:01] Aimee Trescothick: think what? I missed the start of the conversation
  • [14:01] xstorm Radek: rob i seen you to many times now
  • [14:01] Aimee Trescothick: hi Rob :)
  • [14:01] xstorm Radek: *GIGGLES* :)~[14:01
  • [14:01] Merov Linden: Hi there
  • [14:01] xstorm Radek: Rob you do look like that in real life right ?
  • [14:02] Aimee Trescothick: hi Merov :) thanks for the patch reviews, +1 on the comment thing :)
  • [14:02] Rob Linden: more or less
  • [14:02] Merov Linden: you're welcome Aimee
  • [14:02] xstorm Radek: hi Merov :-)
  • [14:03] Merov Linden: hi xstorm
  • [14:03] Rob Linden: oh, did Merov actually deprive us of an agenda? :)
  • [14:03] Aimee Trescothick: lol
  • [14:03] Merov Linden: I also do look like my avatar :)
  • [14:03] xstorm Radek: looks that way yes
  • [14:03] Merov Linden: rather less than more...
  • [14:03] Rob Linden: [1]
  • [14:03] Thickbrick Sleaford: I added a couple of jira items with patches an hour ago
  • [14:04] Thickbrick Sleaford: (to teh agenda)
  • [14:04] xstorm Radek: well if i was 29 years younger i will have look like my av
  • [14:04] xstorm Radek: *GIGGLES* :)~[14:04
  • [14:04] Morgaine Dinova: Wo, it's CG --- hiya stranger :P
  • [14:05] Rob Linden: well, let's take a look
  • [14:05] xstorm Radek: old men can stay how they remember them self
  • [14:05] Rob Linden: at first glance, I thought one of them was a patch that Aimee was looking for a review on, but I guess it isn't
  • [14:05] Rob Linden: VWR-9287[c
  • [14:05] JIRA-helper: http//jira.secondlife.com/browse/VWR-9287:
  • [#VWR-9287] hotkeys to: select next/previous prim in a link set
  • [14:06] Free Radar: HUD v1.1 by Crystal Gadgets
  • [14:06] Thickbrick Sleaford: Soft commited that to maint-viewer-15, so my question is if it makes sense to add to Snowglobe as well
  • [14:06] Aleric Inglewood: gotta hate those crashes while being in a meeting about the viewer
  • [14:06] Rob Linden: there's some debate about that amongst the Lindens
  • [14:06] Rob Linden: (I think, maybe not)
  • [14:06] xstorm Radek: oh i will vote on that one
  • [14:07] Rob Linden: the debate stems from whether we merge in individual fixes that have been committed to maint-viewer-13a and maint-viewer-15, or if we try to take those branches wholesale
  • [14:08] Rob Linden: the downside of taking the individual patch is that it might get stomped in a merge of the branch down the line
  • [14:08] Rob Linden: however, I may be characterizing this as a controversy where there is none
  • [14:08] Merov Linden: I've a question though I should know the answer: what's the code baseline of maint-viewer-x? 1.23? trunk? other?
  • [14:09] Rob Linden: lemme ping Soft and ask
  • [14:09] Rob Linden: I'm pretty sure they both branch from trunk
  • [14:09] Morgaine Dinova: Robin: very first post to your Snowglobe group failed.
  • [14:10] Robin Cornelius: `Morgain what group chat? or notice?
  • [14:10] Robin Cornelius: *can't spell
  • [14:10] Morgaine Dinova: Robin: group chat
  • [14:10] Aleric Inglewood: I saw neither
  • [14:10] Thickbrick Sleaford: I'd like to ask the opposite question: when are they planned to be merged with the main LL viewer?
  • [14:10] xstorm Radek: when trying to when your working with 200 linked prims you need a tab link part to reset the root prim
  • [14:11] Rob Linden: mv13 and mv15 are from trunk
  • [14:11] Rob Linden: both of those are published, right?
  • [14:12] Thickbrick Sleaford: maint-viewer-15 is in public svn
  • [14:12] xstorm Radek: that be great for snowglobe
  • [14:13] Rob Linden: hmm....I'm actually not seeing them
  • [14:13] xstorm Radek: think of it we can push snowglobe at the best for builders and EDU
  • [14:14] Thickbrick Sleaford: oh, there's jsut a maint-viewer branch
  • [14:14] Morgaine Dinova: Robin: 3rd and 4th posts failed too
  • [14:14] Merov Linden: Rob: the branches/2009/maint-viewer is synced up with maint-viewer-15
  • [14:14] Rob Linden: oh, wait nm
  • [14:14] Rob Linden: yeah, I forgot, we aggregate them now
  • [14:15] Rob Linden: the published versions of those branches aren't maint-viewer-*, they're just maint-viewer
  • [14:16] CG Linden: yep :)
  • [14:16] xstorm Radek: hi CG :-)
  • [14:16] Rob Linden: ought to make merging....interesting
  • [14:16] Merov Linden: and those maint-viewer-x all branch from trunk?
  • [14:16] Rob Linden: merov, yeah
  • [14:17] Rob Linden: up to and including mv-15
  • [14:17] Merov Linden: k
  • [14:17] Merov Linden: so, rebasing snowglobe on mv means rebasing from trunk basically
  • [14:18] Rob Linden: well, we could handle it the way we did the easybuild merge
  • [14:18] CG Linden: Yeah.... why would that be bad?
  • [14:18] Merov Linden: I thought we were shying away from this 'cause trunk is not stable, right?
  • [14:18] Rob Linden: Merov: we shied away from it for 1.0 because of schedule pressure
  • [14:19] Morgaine Dinova: Robin: my "Testing" message in Snowglobe group was my message #2. After that one, no other mesages came out until 2/10 (10th message)
  • [14:20] Merov Linden: ok Rob, so, I've no religion against rebasing from trunk really (or mv...)
  • [14:20] Rob Linden: back to my comment on easybuild, the idea there is not to rebase on trunk, but instead take the delta from trunk. that may not be feasible, but if everything is truly a maintenance fix, it might work
  • [14:21] Rob Linden: (that is, not actually take the trunk changes, just take everything after the trunk merge)
  • [14:22] Rob Linden: anyway, one question for CG and Merov...
  • [14:22] Aleric Inglewood: I never could attend this meeting, because it is on Thurdays... But, this being an "open source" meeting, isn't it automatically about snowglobe and snowglobe only? Just asking because you talk about an "easybuild branch"
  • [14:23] Rob Linden: cg and/or merov: if we start cherrypicking patches that are already in mv13a and mv15, how much tougher does that make an mv merge?
  • [14:23] CG Linden: I think an attempt should be made to sync up with trunk.
  • [14:24] Merov Linden: hmmm...
  • [14:24] CG Linden: cherrypicking tends to not make things any easier in the long run... if we can't sync, then there is no point in having trunk
  • [14:24] xstorm Radek: true
  • [14:25] Rob Linden: could we get some help with that? :) I ask that because Merov has been bravely managing these big merges, so I'm hesitant to sign him up for mroe when I know he would like to get back to feature development
  • [14:25] CG Linden: /is blatantly talking about Merov's time and nerves - apologies :)
  • [14:25] Merov Linden: cardia arrest
  • [14:26] Merov Linden: well, the thing with cherrypicking is that managing the conflicts in a meaningful way is hard
  • [14:26] xstorm Radek: oh no is he not for us to keep ?
  • [14:26] Rob Linden: I could attempt it, but I'm not sure you *really* want me in there doing that. though, who knows, that might be a good area for me to get my feet wet
  • [14:27] Dzonatas Sol: hard with subversion, or is there another repos or tool that would make it easier?
  • [14:27] Morgaine Dinova: Cherry picking allows the community viewer to have features that are of no current business interest to Linden Lab. If you throw away cherry picking, this implies that all patches to Snowglobe need to be in tune with current LL buinsess plans. That quite scuppers any view that Snowglobe is a community viewer.
  • [14:27] Merov Linden: I discovered (the hard way...), that when you have lots of conflicts, you better merge rev one at a time and understand the whole range of changes, not just the conflicting ones
  • [14:27] Rob Linden: yes, we still want to get moved to Mercurial. the folks on the release team (which includes CG) are workign to make that happen
  • [14:28] CG Linden: Morgaine, not necessarily
  • [14:28] Rob Linden: Morgaine: we're only talking about those changes that are already in mv-13a and mv-15
  • [14:28] Morgaine Dinova: Aha!
  • [14:28] Rob Linden: those are headed for a release viewer in the future
  • [14:28] CG Linden: it just means you get all our stuff, and not just mv-13/15
  • [14:28] Morgaine Dinova: nods to Rob
  • [14:29] CG Linden: which would catch the case where something in mv-13/15 happens to depend on the other stuff
  • [14:29] Rob Linden: CG: I dont' think mv-15 is headed back *in* to trunk in the immediate future
  • [14:29] Morgaine Dinova: That's fine. I though you were referring to all future work.
  • [14:29] Harrison Partch: w]
  • [14:29] xstorm Radek: i think snowglobe will be great if it was made better for content builders , EDU and Companys
  • [14:29] Harrison's Google: Translator: w]
  • [14:29] Dzonatas Sol: I would suggest quilt, but I'd imagine that works best with patches that have more stability
  • [14:29] CG Linden: oh? I thought I had a QAR for that lying on my plate...
  • [14:29] Aleric Inglewood: It's way easier to merge in patches you wrote yourself than the other way around. If I expect conflicts because I have local patches (say), I first unapply those, then 'update' (or anything that is expected to be a clean merge) and then attempt to reapply the patches that I am familiar with. (if that helps any)
  • [14:30] Rob Linden: cg: look again
  • [14:30] CG Linden: we need the merge target field :)
  • [14:30] xstorm Radek: take the standard SL viewer and use it for for the every day party people
  • [14:30] Merov Linden: +1 on Aleric strategy, that's the way I understand "base + snowglobe changes"
  • [14:30] Harrison Partch: i am using snowglobe right now
  • [14:31] xstorm Radek: snowglobe will mage a great work horse
  • [14:31] Harrison Partch: 32 bit
  • [14:31] xstorm Radek: make
  • [14:31] Harrison Partch: it doesn't work on 54
  • [14:31] Harrison Partch: 64 bit
  • [14:31] Harrison Partch: but that is the fault of sidux
  • [14:31] xstorm Radek: im running snowglobe on a 64bit server
  • [14:31] Merov Linden: we have much less snowglobe patches than all the mv and other viewer commits
  • [14:32] Harrison Partch: right now debian unstable libc6 is incompatible with ia32libs
  • [14:32] RaptonX Zorger: is running it in vista 64
  • [14:32] Rob Linden: hmm....well, let's get back to the immediate question at hand:
  • [14:33] Rob Linden: we've got a couple of patches from Thickbrick
  • [14:33] Rob Linden: one (or both?) are already in mv
  • [14:34] Rob Linden: should we give the green light to get them into Snowglobe now?
  • [14:34] Thickbrick Sleaford: just VWR-9287 is in mv
  • [14:34] Thickbrick Sleaford: and the patch for that only touches one cpp and one xui file - only adds lines IIRC
  • [14:36] Rob Linden: doublechecks the internally committed version, to see if Soft made any changes on the way in
  • [14:37] Mm Alder: Right now snowglobe is based on 1.23, but that can't last. Very soon you'll have to pick another base. YTou move to that new base by applying all of the snowglobe patches. By the time maint-viewer comes around, you can just leave out the patch you stole from it.
  • [14:38] Rob Linden: ok, well, I vote for letting in VWR-9287....anyone object?
  • [14:38] JayR Cela: nope
  • [14:38] Merov Linden: doesn't object
  • [14:39] Thickbrick Sleaford: so I'll make a SNOW jira with any changes Soft added and post to sldev?
  • [14:39] Rob Linden: k...let's just make that the call then
  • [14:39] xstorm Radek: great
  • [14:39] xstorm Radek:  :-)
  • [14:39] Thickbrick Sleaford: I'm not a commiter to snowgloab, anyway
  • [14:39] Rob Linden: VWR-12984
  • [14:39] JIRA-helper: http//jira.secondlife.com/browse/VWR-12984:
  • [#VWR-12984] Water flickers: and disappears in patches
  • [14:39] Thickbrick Sleaford: *snowglobe
  • [14:40] Robin Cornelius: yes i'm for creating a seperate SNOW-xx jira for any issues like this and for mentioning them in the commit log
  • [14:40] Merov Linden: Mm Alder: agree with you, just need to decide when to rebase, which criteria to use (e.g. the base should be stable..)
  • [14:40] Robin Cornelius: just so there is tracability
  • [14:40] Rob Linden: Thickbrick: do we have a contrib agreement on file from you?
  • [14:40] Thickbrick Sleaford: yes
  • [14:40] Rob Linden: let's talk later about maybe making you a committer
  • [14:41] Thickbrick Sleaford: and so does Techwolf, I think - some of vwr-9287 is his additions
  • [14:41] xstorm Radek: i have seen that with snowglobe too
  • [14:41] Rob Linden: (if you're interested)
  • [14:41] Rob Linden: so, back to VWR-12984
  • [14:41] Aleric Inglewood: VWR-12984 says it's a HACK in the comments...
  • [14:42] xstorm Radek: but is that not to do with draw distent ?
  • [14:42] Aleric Inglewood: I'd like to know what is espected to break as result of the hack
  • [14:42] Aleric Inglewood: expected* too
  • [14:42] Rob Linden: good question
  • [14:43] Thickbrick Sleaford: it changes the sizes of water patches to prevent them from being culled incorrectly
  • [14:43] Thickbrick Sleaford: and to compensate by having them overlap
  • [14:43] xstorm Radek: if you are up at 1000 m to 4000 m and draw distent is turn down that happens
  • [14:43] Thickbrick Sleaford: it also happens at 250 m
  • [14:43] Thickbrick Sleaford: but in a smaller screen area
  • [14:44] xstorm Radek: im not that low :-)
  • [14:44] xstorm Radek: oh im on a 30" +
  • [14:44] Aleric Inglewood: Well, normally if you have overlapping surfaces (ie of prims) it shows as annoying flickering cause the viewer doesn't know what surface to show. I find that highly annoying.
  • [14:44] Thickbrick Sleaford: so I'm not sure about including it, but i have been running with it for the last few weeks, and see now adverse effects
  • [14:44] Saijanai Kuhn: When the agenda allows for it, I'd like to ask a meta-type question...
  • [14:44] Dzonatas Sol: if the textures don't have the same offset, they'll flicker
  • [14:44] Thickbrick Sleaford: *no adverse
  • [14:45] Harrison Partch: I never meta question i didn't like.
  • [14:45] Rob Linden: what's the best way to really put this one through its paces?
  • [14:46] Thickbrick Sleaford: you mean to see the bug?
  • [14:46] Rob Linden: see the expected flickering problem
  • [14:47] Rob Linden: we've got what a lot of people say is a real problem that this issue fixes, but we're also potentially trading one problem for another
  • [14:47] Thickbrick Sleaford: move a cube to above 512 meters, and move the camera around it,, keeping the cube slightly below the horizon
  • [14:47] Techwolf Lupindo: tries to catch up.
  • [14:47] Skills Hak: the higher you go the more noise you get in prim positions
  • [14:47] Skills Hak: thats what is making it flicker
  • [14:47] xstorm Radek: one way we can test it now is to make a prim and lick chair prims on it and send us up to 1000 to see
  • [14:48] Rob Linden: given what Dzonatas and Aleric are saying about the flickering, I'd like to see a plan for testing that that potential effect isn't so bad
  • [14:48] Thickbrick Sleaford: this is an issue with the water patches the viewer adds around you at a distance - they get culled incorrectly
  • [14:48] Skills Hak: i can take you up to 20km or so, there you can see it flicker really good ;)
  • [14:49] Thickbrick Sleaford: it really annoys me, but I guess if there's not much interest it can wait untel there's a better solution
  • [14:49] xstorm Radek: but will such flicker make a high end graphic system unstable to the point it will crash ?
  • [14:49] xstorm Radek: or even buffer lag ?
  • [14:49] Merov Linden: seen that bug while in our meeting skybox of all places...
  • [14:49] Rob Linden: we don't have a test plan field in the external tracker yet, do we?
  • [14:49] Skills Hak: my sims are at 3600m and everything is shaking up there when you zoom in
  • [14:49] Morgaine Dinova: "Getting culled incorrectly" and "noise in position making it flicker" are two completely different things. Which is it?
  • [14:49] Skills Hak: you cant build small scale stuff there
  • [14:49] Skills Hak: even attachments of avatars are shaking
  • [14:49] xstorm Radek: buffer lag is like a rubber band problem
  • [14:50] Thickbrick Sleaford: Morgaine: I'm pretty sure it's the former
  • [14:50] RaptonX Zorger: noticed some prims just vanish when up at certian heights, one of the walls in the store would dissapear when viewed at some angles
  • [14:50] Thickbrick Sleaford: it's just water, not prims
  • [14:50] Morgaine Dinova: I only see it on the water horizon, at 1024m, so I concur.
  • [14:51] Latif Khalifa: it starts to show at lower altitudes tpp
  • [14:51] Latif Khalifa: too
  • [14:51] Latif Khalifa: for me at about 500-600m
  • [14:51] xstorm Radek: if its prims that do to a problem with draw limits on a video card
  • [14:51] Aleric Inglewood: did I miss something? I crashed while trying to create a prim here... and on relog ran into a deadlock during "decoding images".. that's a new one to me :/
  • [14:51] Skills Hak: no its on all systems
  • [14:51] Rob Linden: alright, well, for this one, let's move the discussion to sldev, and work out what a test plan for this one is.
  • [14:51] Skills Hak: it looks like a rounding problem
  • [14:52] Skills Hak: the higher away from 0 you go the worse it gets
  • [14:52] Morgaine Dinova: Aleric: ouch!!!! Deadlock problems are a very bad sign
  • [14:52] Thickbrick Sleaford: I don't think it is - you can see it at 300 meters
  • [14:52] Skills Hak: ona ll viewers all the hardware
  • [14:52] Skills Hak: all*
  • [14:52] Rob Linden: Aleric: you may be running into the OpenJPEG problem that we worked around by making Kakadu the default decoder
  • [14:52] Latif Khalifa: biggest snowglobe problem for me are those random curl crashes, anyone had more luck chaising down what's going on with the new map and curl=
  • [14:53] xstorm Radek: then if thats true its a oh *GIGGLES* :)Rob Linden 23:25, 2 July 2009 (UTC) nvm
  • [14:53] Merov Linden: working on it Latif
  • [14:53] Merov Linden: SNOW-2
  • [14:53] JIRA-helper: http//jira.secondlife.com/browse/SNOW-2:
  • [#SNOW-2] crashers undefined:
  • [14:53] Rob Linden: Saijanai, you had somethign you wanted to bring up?
  • [14:53] Latif Khalifa: Merov, tried to find a solid repro, without luck, also visual studio does not give useful stack traces
  • [14:53] Aleric Inglewood: Rob: Not sure, something is fishy since I started to use libopenjpeg 2.2 for encoding, cause ever since I started to see crashing in decode_image in openjpeg 1.0.3 at times.
  • [14:54] Saijanai Kuhn: ah, yes, its a metao-question about what is kosher to do with snowglobe
  • [14:54] Saijanai Kuhn: meta*
  • [14:54] Merov Linden: Latif: I know, it's unfortunate really
  • [14:54] Rob Linden: fire away...
  • [14:54] Saijanai Kuhn: The background is that a couple of years ago, I had a bright idea for adding a feature...
  • [14:54] Saijanai Kuhn: [2]
  • [14:54] Harrison Partch: have all the possible "Snow Crah" jokes been exhausted?
  • [14:54] Merov Linden: but there's a couple of ideas I looked at and discussed with Zero (who did the initial implementation of LLCurl)
  • [14:55] Saijanai Kuhn: unfortunately I managed to lose the source during an OS upgrade/reinstall so this is hypothetical
  • [14:55] xstorm Radek: i have seen this same error but in the SL Vewer to and snowglobe is it not a server side problem ?
  • [14:55] Saijanai Kuhn: what I noticed was that the classes for folders were all scrunched together, both conceptually and in the source files
  • [14:55] Latif Khalifa: Merov, in my stack traces it ends up in clear_cookies() or some such, strange
  • [14:56] Techwolf Lupindo: Ever sence I built cure with -nss,-gnutls,ares, I have not one curl related crash or problem.
  • [14:56] Saijanai Kuhn: it made i impossible (for me at least) to take the existing folder class and repurpose it for providing hierarchical tree interfaces like for that video
  • [14:56] Techwolf Lupindo: curl that is
  • [14:56] Rob Linden: needs to go in a couple minutes
  • [14:56] Saijanai Kuhn: so I just bypassed the existing inteface and faked my own
  • [14:56] Merov Linden: Latif: the current thinking is that we're using some curl stuff in a thread unsafe way
  • [14:56] Robin Cornelius: Tech does curl not block with gnutls and ares? i thought non blocking was only supported on openssl
  • [14:57] xstorm Radek: thats why its part server side no ?
  • [14:57] Techwolf Lupindo: I need to check, but I think the SL client is making a dns lookup many times a second in certion parts.
  • [14:57] Saijanai Kuhn: my question is: since that kind of source code/design exists throughout the viewer, it makes it hard to mod the viewer in many ways
  • [14:57] Morgaine Dinova: thinks the question is leading to "Can we refactor Snowglobe's inventory, or is that too big a change?" ^_^
  • [14:57] Saijanai Kuhn: e.g. folder class not tied to inventory view, groiup IM windows tied to LL's group IM
  • [14:58] Saijanai Kuhn: Morgaine, worse than that: what refactoring is allowed at what level?
  • [14:58] Morgaine Dinova: Big question, but a good one.
  • [14:58] Saijanai Kuhn: because there's plenty of candidates in the UI, not fust inventory
  • [14:58] Rob Linden: Saijanai: start small
  • [14:58] Latif Khalifa: Merov, I thought that CAPS implemetation was using curl to for http fetches, strange that the bug will appear only with regards to map tiles fetching
  • [14:58] Techwolf Lupindo: Robin, I did have curl with gnutls and ares, I was getting .1 second slowdowns every 1 second. Then got a crash that pointed to the gnutls, so I rebuild curl without it and havn't had a problem sence then.
  • [14:58] Mm Alder: Saijanai, it sounds like you're just reusing a UI widget, no?
  • [14:59] Rob Linden: when someone has been contributing for a while, they're in a good position to call for a redesign
  • [14:59] Saijanai Kuhn: Rob that's the thing. Some of this stuff like folders, is about 5 classes smushed into one in the source.
  • [14:59] Saijanai Kuhn: the first bit of refactoring that would need to be done would simply be tease the classes out into their own source files
  • [14:59] Rob Linden: well....like I said, I've gotta go now. refactoring the viewer is not a last 5 minutes discussion
  • [15:00] Latif Khalifa: Sai, and who do you propose should do this?
  • [15:00] Saijanai Kuhn: no code/behavior changes, just a re-distribution of the source
  • [15:00] Techwolf Lupindo: Is there any reason curl is being use for dns lookups instaed of doing a standerd dns lookup on both linux and windows?
  • [15:00] CG Linden: needs to go to another meeting...
  • [15:00] Saijanai Kuhn: that's the thing: who is allowed to do this?
  • [15:00] xstorm Radek: but to fix it you need to fix server side too and the user side right ?
  • [15:00] Rob Linden: has to run
  • [15:00] Merov Linden: Latif: tile fetching is exercising that code path more
  • [15:00] Rob Linden: thanks everyone
  • [15:00] Aleric Inglewood: bye!
  • [15:00] CG Linden: ciao
  • [15:00] Saijanai Kuhn: xstorm eventually but not for this specific thing
  • [15:00] Mm Alder: Saijania, perhaps you could post more detail to sldev.
  • [15:00] Latif Khalifa: Sai, my question who is willing?
  • [15:00] Robin Cornelius: ANyone not got a snowglobe invite who wants one please ping me
  • [15:00] Morgaine Dinova: Cyu Rob et al
  • [15:00] Merov Linden: so making the likelyhood of having a thread safety bug show up higher