I'm very happy with the solution as it is now. It's the result of a democratical process. Respectful discussion is necessary to find a solution that works for all, keep that in mind before blaming each other and starting a drama next time.
On Tue, Nov 17, 2015 at 7:08 AM, Teravus Ovares <[email protected]> wrote: > While I understand your frustration here is more about who made the change > and who it's connected to which is a political thing... For me, it's not > at all a political problem and entirely a technical problem. Nobody knew > during the 3 months you mentioned..... the affect it would have on > existing viewers. > > It certainly wasn't DISCLOSED BY YOU that that the change would make > viewers with a Lag meter show the sims as perpetually laggy. > > I'm not saying that you did anything wrong... at that point... you > probably didn't know either... since, you said for yourself, for the most > part you're using your own WebGL stuff because the viewer licensing is very > complex. > > Even though before, I didn't think you were doing anything wrong.... , > now... I feel like you ARE doing something wrong in the way that you're > handling this. > > What cost are you willing to accept to make a stat accurate and NOT make > some kind of compromise like I suggested... ,that Melanie had ALREADY > implemented by the time I suggested it? Are you willing to make > OpenSimulator less usable for many users so you can have certain bits in > the stream in a certain spot and are not happy with it being in a separate > spot to keep everything usable for a wide audience? > > I understand that you 'were' trying to help. However, it seems to have > morphed into an attempt at manipulation through politics. I know you're > frustrated... I understand that it is HARD to work in groups and > coordinate teams. I have dealt with this MANY times during my > OpenSimulator contributions. It is super frustrating when I'm super > excited about a nifty new functionality that I contributed... only to > have someone in core say it breaks something important and have it forced > to be relegated to a configuration option... It is frustrating.. it > really is. However, when working with teams... GOOD communication and > coordination is REQUIRED. I cannot go on my own and expect everything to > be nice and simple when I hand over a slab of code that I worked on > separately. I also can't make tsunami waves until I make some normal sized > waves that people enjoy surfing. While communicating with someone... > the onus is on me, being the one doing the communicating, to be sure that > the other party understands and receives my message clearly. I can't > expect them to read my mind or react well to increasing frustration. > Frustration is an unfortunate part of the code contribution process. Have > you ever contributed code to Linux? Are you ready to have your coding > skills over analysed by hundreds of developers.. some of whom have > absolutely no manners? > > Then, you made a public stink about reporting statistics. Which was cool > because we do want accurate stats... I said before that I wanted accurate > statistics (It has been repeated in these communications multiple times)... > however I WARNED to be careful with the stats because of the viewer > issues. > > In the end, it DID cause problems with the viewer. Unfortunately, for us, > it is entirely impractical to expect all viewers to change... When the > viewer developers DO make concessions and change, we are EXTREMELY > grateful. Those viewer code bases are NOT easy to deal with. In the end, > the only thing that I have control over is myself. > > So, technical solutions were proposed.... and here's where I think it > went wrong. Instead of compromising and working out a solution > constructively... there was all of this drama and finger pointing... > and instead of dealing with it constructively you struck out against the > fact that it was there and made accusations against people based on their > affiliations. Then, you doubled down on that.... all the while, a > simple fix to what now was a BUG was implemented to resolve the issue for > the immediate... and ACTUAL constructive solutions were being devised and > implemented for the long term. > > From a technical perspective, it is super simple to report the 'accurate > stats' in another place and make sure it's highly documented. SIMPLE > to do. It doesn't require all of this drama... > > Much like you called out the code on the FPS issue, I'm calling you out on > the political drama now. It is entirely unnecessary and even harmful at > this point. Instead of focusing on a solution that will work for > everyone.. you're sticking on this one thing... over and over again. > How many times can you beat that dead horse? Thank you for letting us > know. The community is aware of that issue now. You have successfully > brought it to our attention and solutions are being devised and implemented > so proper testing can be done.. if not by you then other people. > > "The bridges are burned.", OK. That's a stance of someone who > doesn't really care anymore. I'm fine with that. For me, it means, > less drama, more constructive solutions. Again, you successfully brought > that issue to our attention. Thank you for your contributions to > OpenSimulator and I wish you well in your future endeavors. May they be > awesome and innovative and wildly successful. > > Lets move on to other technical issues. > > Regards > > Teravus > > > > On Mon, Nov 16, 2015 at 8:56 PM, dz <[email protected]> wrote: > >> >> >> On Mon, Nov 16, 2015 at 7:33 PM, Teravus Ovares <[email protected]> >> wrote: >> >>> Regarding this... why are we not co-opting a different, currently >>> unused, sim stats for the OpenSimulator 'Real performance' counter? There >>> are many unused simstats. If we keep the fudge factor on the main one, >>> the viewer lag meter are happy, and we put the real value in a different >>> sim-stat, the performance analysis can take place accurately. >>> >>>> >>>> >> Teravus.. >> >> The whole point of starting this conversation was that WE HAD THESE >> CONVERSATIONS.. We had a community forum discussion on how to implement >> reporting of the correct statistics. The Moses group found a comment >> buried in the source code and asked about WHY someone decided to multiply >> the Physics frame rate ( which is LOCKED at 11 FPS ) by a factor of 5... >> No one on core could really explain it until Justin suggested reaching >> out to you.. That grew into a discussion of whether it made any sense to >> continue to report "politically correct" numbers or the actual Physics >> frame rate. The overwhelming majority of the people who responded >> indicted that it didn't make ANY sense to continue reporting the bad >> stats. The answers we got from the core team was that it might break >> performance monitoring scripts or have an effect on some internal >> calculations... There was an extended period of discussion to allow folks >> to make suggestions or comment on the things that would break It took >> almost 3 months from the beginning of the discussion to the time it was >> applied. There was NO guidance from core that it was in any way important >> to maintain the functionality of an obscure feature in some un-maintained >> viewer code. >> >> The objection I raised to begin this debacle was that it seemed like a >> member of core had just randomly decided that after 3 months of asking >> folks to jump through hoops, and then 6 months of having the sky NOT >> fall, it was ok to make a unilateral decision to revert the patch ( or >> override it with some new hidden config variable that would only >> continue the confusion about what the actual Physics FPS rate was). >> >> After all is said and done...It still seems to me like that is the >> situation... I have given up trying to get any real discussion about >> who it was that demanded that we revert the patch so their NON ACCURATE >> lag meter blinks green instead of red. We have heard form other grid >> owners, we have heard from viewer devs, we have heard from academics >> whose reputations may have been tarnished by publishing incorrect data. >> Bottom Line... One core member has decided that it is ok to ignore the >> efforts of this forums community and introduced a solution that lets the >> same code base report 55 OR 11 for the exact same statistic in the exact >> same code base, Its also been decided that it is STILL correct to add >> yet another level of complexity and possible source of confusion to the >> situation by renaming our Fudge factor/lie the NORMALIZED number. >> >> I can't code like members of core, I can't seem to influence the >> decisions they are determined to make with regards to this insanity.. >> This is not a technically complicated issue... it is simply a matter of >> making a decision about what is correct. Apparently " correct " is >> related to the Euros that some unknown benefactor is willing to put up to >> make the lights blink green. WE ( nearly 95% of everyone who >> participated in the original period of discussion) had agreed that >> reporting the correct number was the right thing to do MOSES spent >> manpower and money to go through the process of getting a patch >> submitted/corrected, and applied, It WAS NOT a problem for anyone >> except for some unknown users on some unnamed grid ( who have YET to >> speak for themselves ). My objection remains... It is NOT proper to be >> able to bypass the community decision making nature WE assumed was the >> proper mechanism to resolve such issues. We have had close to 150 >> posts on this topic in the past 2 weeks and NO ONE has been able to >> explain why it is the correct decision to revert the patch AND ignore the >> requests and almost unanimous agreement that the way things have been for >> 6 months was the best technical and political decision. >> >> I am committed to making OpenSim work.. I am sure there are folks who >> have seen this debacle unfold who are now less committed or interested in >> trying to participate >> with a technical group that believes it is politically "correct" to set >> such a precedent ( ignoring community forum input in favor of backroom >> "deals")... How can there possibly be a level of confidence in the >> platform/community if it takes 9 months to come to an agreement that a >> Physics Frame Rate that is LOCKED at 11FPS should not be reported at 11 >> FPS??? Its not a complicated situation, It isn't a hard question... >> But it has turned into a real eye opener on the inside workings of this >> project for me (and from the comments I've received offline, for a large >> number of others). >> >> The lag meter didn't work before the numbers changed. At best it was a >> random guess that was likely at least 10% off. The original code would >> cast the floating point FPS number to an int before multiplying by some >> random factor of 5 to make sure that jitter didnt skew it wildly... It >> STILL doesn't work. Even the viewer devs who participated and went >> through the trouble to correct for the 11FPS number told us, the % >> levels at which the lights are green, yellow , or red are different >> for OpenSim and "that other grid". Melanies' solution means that now >> they have to rework their code to use her new magical mechanism to >> transmit the number 5 from Opensim to the viewer so it can do the >> multiplication...It also means that grid operators have to be able to >> explain why the same stat on different grids can be just as correct when >> it says 11 as when it says 55. That's not my problem, but I feel >> sorry for the honest grid operators who choose to tell the truth, and >> face charges that their grid is 5x slower than some other grid where >> the admin doesn't even know enough to change the new INI config value. >> >> Do I sound frustrated yet? >> >> Please don't ask that question NOW.. The bridges are burned. >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
