Chat log from the meeting on 2019-02-05

From OpenSimulator

Revision as of 13:10, 5 February 2019 by Sheera Khan (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

[11:06] Andrew.Hellershanks There was a lot of commits to the OS code base this past week. Mostly by Ubit. Also some BulletSim related commits by Misterblue.
[11:09] Andrew.Hellershanks What do you want to talk about this week?
[11:10] Gavin.Hird I see Metro is planning a major upgrade to 0.9.1
[11:10] Sheera Khan: that will be a huge step ;-)
[11:10] Andrew.Hellershanks Gavin, what sort of upgrade(s)?
[11:10] Sheera Khan: Two steps even
[11:10] Gavin.Hird will there be a stable release before they do?
[11:11] Gavin.Hird migrating the entire grid to 0.9.1
[11:11] Ubit Umarov: large grids should not depend on releases
[11:11] Sheera Khan: I think Zak took a version and then did some cherry picking...
[11:11] Vincent.Sylvester Actually on the topic of the commits the past couple days. I spent some time going through some old stale issues on mantis trying to either confirm the reports or close unrelated reports from modules and code long gone. I would like to ask what to do about those that are assigned to developers that are no longer active in the project?
[11:11] Andrew.Hellershanks Gavin, oh. :) I thought you meant they were making big changes to the 0.9.1 code base. :)
[11:11] Ubit Umarov: at least on true bug fix commits
[11:12] Gavin.Hird
[11:13] Ubit Umarov: about new release, well yeap we should do one
[11:13] Ubit Umarov: but i keep changing things :p
[11:13] Gavin.Hird stop that!
[11:13] Gavin.Hird :-)
[11:13] Ubit Umarov: :)
[11:14] Vincent.Sylvester I am partially at fault for reporting things to Ubit all the time ;)
[11:14] Bill Blight: would rather see constant movement forward than worry over releases ..
[11:14] Ubit Umarov: well but many, correctly only use releases
[11:15] Ubit Umarov: and getting outdated on bug fixes
[11:15] Bill Blight: which is silly, IMHO, pick a day, pick a commit call it release, no different than any other ..
[11:16] Ubit Umarov: well release cycle was suposed to be more complex
[11:16] Bill Blight: supposed to be and ends up being are hardly ever the same
[11:16] Ubit Umarov: release candidates.. wait for feedback.. other candidate.. wait...
[11:16] Ubit Umarov: then release
[11:16] Bill Blight: Which just puts development in a holding pattern
[11:17] Dev Random: makes sense if you're doing LTS releases.
[11:17] Bill Blight: would be different if the project had a bunch of devs and teams working on things
[11:17] Andrew.Hellershanks Not neccessarily as code can still be changed on master.
[11:18] Ubit Umarov: well a RC is usually taken out to a branch
[11:18] Ubit Umarov: so master can go on
[11:18] Andrew.Hellershanks Right
[11:18] Gavin.Hird make a release repository and only merge in the release point to it
[11:18] Ubit Umarov: but a bit harder when its the same neuron doing both :)
[11:19] Bill Blight: That was my point, hard to do a release and wait for input on it, when the same person is also working on master,
[11:19] Ubit Umarov: we use branches on that
[11:20] Andrew.Hellershanks I was checking the dates. was released about end of June last year.
[11:20] Gavin.Hird yes, but it can get messy to do everyting in one repository
[11:20] Bill Blight: yes and 9x is what 3 years old now
[11:20] Ubit Umarov: well its doable
[11:20] Ubit Umarov: git does survive :)
[11:21] Gavin.Hird I do the same now with the viewer code, so who am I to talk, but ideally
[11:22] Bill Blight: Ideally there are people to manage the project not just worker bees ...
[11:22] Ubit Umarov: and i have several issues "open"
[11:22] Gavin.Hird true
[11:22] Ubit Umarov: a few changes on tps
[11:22] Vincent.Sylvester Some of which are a decade old I have found...
[11:23] Ubit Umarov: going on replacing osd on simple serialization
[11:23] Gavin.Hird there is this bulletsim one where collisions suddenly stop to work
[11:23] Ubit Umarov: on event caps
[11:23] Gavin.Hird I sort of rediscovered it yesterday
[11:23] Ubit Umarov: well mantis we usually leave to reporter to close issues
[11:24] Ubit Umarov: so many even fixed never get closed
[11:24] Dev Random: lol Gavin.. that's been bothering me for years...
[11:24] Ubit Umarov: bullet still stops collisions?
[11:24] Bill Blight: That one is easy to fix .............use ubODE
[11:24] Bill Blight: :P
[11:24] Dev Random: lol
[11:24] Dev Random: Ubit, yes....
[11:24] Gavin.Hird it just randomly stops
[11:25] Gavin.Hird at least for scripts
[11:25] Andrew.Hellershanks Gavin, is there an open mantis relating to the collision problem?
[11:25] Gavin.Hird there is
[11:25] Gavin.Hird assigned to Mr. Blue
[11:25] Andrew.Hellershanks ok.
[11:25] Ubit Umarov: well script reports is a sub part of the process
[11:26] Ubit Umarov: one case is what i call at ubode sleeping bodies
[11:26] Gavin.Hird it does collide in the sense that you bump into things that stop you and the viewer gives the collision sound
[11:26] Gavin.Hird but the script stop to sense the collision
[11:26] Ubit Umarov: ie if a object is not moving for a while, it is taken out of simulation
[11:27] Gavin.Hird well, a hypergate is not supposed to be moving
[11:27] Ubit Umarov: if it is on top of other that expects collsion event, its possible it also stops it
[11:27] Gavin.Hird but the script should not stop sensing the collision
[11:27] Ubit Umarov: i had that issue with ubode and fix is still a mess
[11:28] Gavin.Hird other example I have is a door autosensing and opening, but they too stop to sense
[11:28] Ubit Umarov: well should not
[11:28] Ubit Umarov: better reactivate those mantis and hope MB has time to see
[11:29] Vincent.Sylvester The best workaround I have found so far is using sensorrepeat and recreating the sensor each time a detection is made, thus keeping it fairly fresh. That has not failed me yet.
[11:30] Vincent.Sylvester Yes, like I have, bump older confirmed bugs. Mantis has over 1300 issues that still need a workover if they are still a problem or not.
[11:30] Ubit Umarov flüstert: well not sure what bullet issue is, just guessing :)
[11:30] Andrew.Hellershanks I just mentioned the collision issue to MB as a reminder.
[11:30] Gavin.Hird great
[11:31] Ubit Umarov flüstert: ( Bill did point out a good solution hihihi )
[11:31] Vincent.Sylvester This is mantis 7132 btw
[11:32] Ubit Umarov: collision event is terrible
[11:32] Gavin.Hird they can even be fatal....
[11:32] Ubit Umarov: hate how so many AOs still use it
[11:32] Bill Blight: Not sure why people are still avoiding ubODE, unless it is just because of old mesh crap
[11:34] Dev Random: I'd imagine some people put significant work into building for Bullet when it was the default...
[11:34] Vincent.Sylvester People fear new stuff, having to update scripts, mesh, it's laziness
[11:35] Gavin.Hird I have hundreds of mesh items (same type) I would need to replace
[11:35] Bill Blight: but there is no difference in building RIGHT for bullet and building RIGHT for ubODE
[11:35] Andrew.Hellershanks I have to tear apart a region to track down some thing causing a high CPU load. I think it may be bad mesh.
[11:35] Bill Blight: the issue is people built lazy
[11:36] Gavin.Hird I can spend time on fixing old meshes, or I can spend time on the viewer
[11:37] Ubit Umarov: well one day bullet will need to change on that also
[11:37] Ubit Umarov: don't see how to proper handle physics shape type without that
[11:38] Gavin.Hird the biggest issue is that for bullet you can use a plane for the physics mesh, while ubode needs double collision surfaces for the same purpose
[11:38] Gavin.Hird so it simply takes time to redo
[11:38] Vincent.Sylvester Most common thing I have heard in OpenSim "It should just work", anything that has potential to incur any form of debugging means "put it off until it breaks", it's the same with code. OpenSim has 44 warnings currently disabled, some of which are for obsolete code. I have heard from a friend over at RedHat that MS plans to release a new version of .NET that will likely remove these now marked as obsolete methods entirely. It is not clear whether they are actually splitting .NET into .NETe and .NET5, but either of which is may not support these old methods.
[11:38] Ubit Umarov: it only needs double if you do really need double
[11:38] Bill Blight: 44 warnings?
[11:39] Bill Blight: I have 3
[11:39] Gavin.Hird often you do need double
[11:39] Gavin.Hird for a wall
[11:39] Gavin.Hird I mean collision from both sides
[11:39] Vincent.Sylvester The warnings are disabled so a compile does not issue them
[11:39] Ubit Umarov: yes i know
[11:40] Vincent.Sylvester pragma warning disable, 44 times in 37 files
[11:40] Vincent.Sylvester Most of these are warnings that can be ignored, but some warn about obsolete methods in .net
[11:40] Ubit Umarov: but if are a builder working at that level, adding the needed faces is not a major issue
[11:41] Ubit Umarov: and single side does reduce potencial instabilities on code
[11:41] Sheera.Khan It may well be if you didn't create the item yourself and the builder isn't around anymore ...
[11:41] Ubit Umarov: ( and makes it faster, so reducing a bit the cost of extra faces )
[11:42] Ubit Umarov: well opensim has tons and tons of bad old things
[11:42] Ubit Umarov: scripting is another case
[11:42] Bill Blight: It is a instance of , just because it was done that way, and you can't find the original builder, does not mean everyone should be saddled with doing it the old way. At some point things need to change, update, move forward ..
[11:42] Ubit Umarov: amazing the things X kinda allows
[11:43] Ubit Umarov: and Y will just refuse
[11:43] Ubit Umarov: because its just bad code
[11:43] Vincent.Sylvester the other way round exists too
[11:43] Ubit Umarov: so more use of Y will bring also issues on scripts
[11:43] Vincent.Sylvester Mantis 5023
[11:46] Ubit Umarov: hopefully new objects/scripts will show up and ppl will change to them
[11:46] Ubit Umarov: well old ode physics things .. also a lot around
[11:46] Ubit Umarov: that don't work well on bullet or ubode
[11:47] Ubit Umarov: to what extent should us allow old in same cases bad legacy things stop new improved solutions?
[11:47] Bill Blight: exactly
[11:48] Dev Random: need a deprecation strategy... support for a period, and then disable.
[11:48] Gavin.Hird kill sculpts
[11:48] Ubit Umarov: well those still work on everything :)
[11:49] Gavin.Hird but horribly so
[11:49] Ubit Umarov: not that horrible
[11:49] Ubit Umarov: making them is horrible :)
[11:49] Gavin.Hird pretty horrible viewer side
[11:50] Ubit Umarov: yeah making a mesh of them is .. confusing :)
[11:50] Gavin.Hird hehe
[11:50] Gavin.Hird good luck with that, haha
[11:50] Ubit Umarov: me and mel had a fight with those on the unreal viewer
[11:51] Ubit Umarov: libomv does not do well some tricky things that ll viewers do show
[11:51] Ubit Umarov: primmesher with visual mesh i mean
[11:52] Gavin.Hird DAZ hexagon and Zbrush can both open sculpts and the result leaves a lot to be desired
[11:52] Ubit Umarov: but region side, they do work
[11:52] Ubit Umarov: well most at least :)
[11:53] Gavin.Hird like sculpted panel trees with 16k faces that can be replaced with a 6 poly mesh that looks identical
[11:53] Ubit Umarov: hmm bullet does detailed collisions on those? dont remember
[11:53] Andrew Hellershanks: We are at 7 minutes before the top of the hour. Does anyone have another topic they wanted to talk about before we wrap up for the day?
[11:54] Gavin.Hird There was a new viewer build a few days back which brings it to parity with LL general bug fixes and small improvements. Can be found at the usual place
[11:54] Vincent.Sylvester What should be done about the tickets assigned to inactive developers?
[11:55] Gavin.Hird The version with the Vivox 4.9 SDK client are compiling now
[11:55] Andrew Hellershanks: Vincent, reassign them or just remove the assigment.
[11:56] Vincent.Sylvester I don't have the necessary permissions on mantis to do so unfortunately that is why I am asking.
[11:56] Andrew Hellershanks: Are there many mantis reports in that state?
[11:57] Vincent.Sylvester Probably a dozen or so
[11:58] Bill Blight: send me the numbers I can do it
[11:58] Andrew Hellershanks: ok. If you would post a message to the mailing list with the mantis numbers someone with the proper permissions can make the changes.
[11:58] Andrew Hellershanks: or sent them to Bill. :)
[11:59] Bill Blight: send them to me in IRC, I'll get to them soon
[11:59] Dev Random: lol.. Justin probably has 50
[11:59] Vincent.Sylvester Yep
[11:59] Vincent.Sylvester Not that many, but yeah, and they are often critical things
[11:59] Vincent.Sylvester I have not gotten around to those yet, I plan to check them and if possible either confirm or resolve them
[12:00] Vincent.Sylvester Mantis has so many unresolved issues that the critical stuff seems to have been buried in them
[12:00] Sheera.Khan Justin has 54 open Mantis
[12:00] Sheera.Khan this page shows them:
[12:01] Vincent.Sylvester In total over 1300 issues are still on Mantis, with likely half of them in an untouched state since their initial opening
[12:01] Vincent.Sylvester Hopefully I can help reduce that mess in the coming days, but I would not mind some help :)
[12:02] Gavin.Hird this one sounds like a good candidate to look at 0006882: Patch to Clean Up XEngine.cs
[12:02] Bill Blight: should just assign them to Ubit?
[12:02] Bill Blight: LOL
[12:02] Gavin.Hird has a lot of patches attached too
[12:02] Andrew Hellershanks: Bill, I was thinking that. :)
[12:02] Vincent.Sylvester Yep, where possible I try to confirm those still build with master to maybe have the implemented at some point
[12:03] Andrew Hellershanks: It would be good to see open reports with patches resolved.
[12:03] Gavin.Hird that would be a good start
[12:03] Andrew Hellershanks nods
[12:04] Vincent.Sylvester Afterwards do a release candidate and see if we broke anything in the process :D
[12:04] Andrew Hellershanks: hehe
[12:07] Andrew Hellershanks: Any last thoughts before we wrap up todays meeting?
[12:07] Andrew Hellershanks: I don't see anyone else starting to type anything so that will do it for this week.
[12:08] Andrew Hellershanks: Thank you all for coming. See you again next week.

Personal tools
About This Wiki