3/2/2023 0 Comments Phoenix viewer rlv![]() ![]() What of Firestorm? We're faced here with two conflicting demands: a group of users who want it, and a group of users who will only use it if it's been sufficiently de-sucked. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. The answer is to release much more often. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release. He caused a lot of needless pain and agony.) Those delayed the release even further, and got in the way of proper beta testing as we quickly approached the deadline we'd publicly set. Then we had a couple of showstopper bug reports - including one that was submitted to us that we agreed to fix before the release, but that apparently didn't satisfy the user, who submitted an abuse report with Linden Lab over it! (I really, really hope I don't find out who that idiot is. One user submitted a patch, after that version went out in beta test, to extend the reach into local chat windows - but we couldn't add it, at that point, because we were trying to lock it down tighter for the formal release of what became 725. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. As I've said before, that's the norm in open source development. The original feature was added by a developer scratching his own itch. On top of that, it also reduces the pressure to just push something out before it's really ready, by keeping users happy that features are being introduced and bugs fixed on an ongoing basis.Ī case in point here is the support for Display Names. Releasing early and often both tends to compartmentalize the addition of features and the corresponding bugs, and also tends to make bug resolution easier and closer to the introduction of whatever caused the bug. Regardless of the reason, the end result was the same: we wound up having to do a lot of debugging, and releasing with bugs we'd rather have fixed. Part of the reason there is that the release was delayed for a while, waiting first on my fix of a nasty texture upload issue, and then the completion of the parcel Windlight settings feature. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. The release of 1.5.2.725 - what we're calling a release candidate, mainly in self-defense - was delayed by quite a bit of time relative to our previous schedule of releases. This has relevance to the current state of the Phoenix Viewer project. This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development. ![]() One of open-source guru Eric Raymond's favorite sayings is " Release early, release often". Once that happens, though, expect Phoenix to be finalized. ![]() There will be bug fixes, at least until Firestorm reaches production release status. This is a final release only in that new versions likely won't have significant feature additions. We hate having a viewer out there with problems as much as the users hate having to deal with problems. We're also tired of chasing some persistent bugs that simply don't exist in the V2 codebase.Įven so, as we fix things, there will be more releases of Phoenix. In particular, display names and multi-attach are in and working about as well as they can be. The difference between now and a couple of months ago, when I first said that we weren't feature-freezing Phoenix yet, is that the developers believe that the major features that can be added to Phoenix have been. (I can't speak for Jess, but I expect that new features that can be dropped in without significant effort will be added - as long as they're added to Firestorm first.) All new feature development will happen in Firestorm, and only get backported to Phoenix on a time-available basis. It will get bug fixes, but no new features, at least officially. There are bugs left in Phoenix that need fixing, mostly in the areas of RLV, texture video memory management, and the new inventory system LL keeps trying to push out, AIS.Īt this point, however, Phoenix is feature-frozen. Just as with any other human endeavor, no program is perfect. The only program that's bug-free is one that's never used. We put a lot of work and fixes into it, and pushed even harder to release 818 by Christmas. By now, if you've been following the saga of Phoenix, you know that 725 was less than a total success. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |