Sigh. By now, if you've been following the saga of Phoenix, you know that 725 was less than a total success. We put a lot of work and fixes into it, and pushed even harder to release 818 by Christmas.
It's better, but it's still got bugs. (Film at 11.)
The only program that's bug-free is one that's never used. Just as with any other human endeavor, no program is perfect. 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.
At this point, however, Phoenix is feature-frozen. It will get bug fixes, but no new features, at least officially. (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.
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. In particular, display names and multi-attach are in and working about as well as they can be. We're also tired of chasing some persistent bugs that simply don't exist in the V2 codebase.
Even so, as we fix things, there will be more releases of Phoenix. We hate having a viewer out there with problems as much as the users hate having to deal with problems. This is a final release only in that new versions likely won't have significant feature additions. There will be bug fixes, at least until Firestorm reaches production release status. Once that happens, though, expect Phoenix to be finalized.
26 December 2010
04 December 2010
Release early, release often
One of open-source guru Eric Raymond's favorite sayings is "Release early, release often". This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development.
This has relevance to the current state of the Phoenix Viewer project. 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. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. 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.
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.
The answer is in Eric's dictum. 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. 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.
A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. 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.
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. 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. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.
The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.
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. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.
I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.
Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.
This has relevance to the current state of the Phoenix Viewer project. 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. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. 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.
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.
The answer is in Eric's dictum. 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. 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.
A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. 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.
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. 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. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.
The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.
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. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.
I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.
Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.
02 December 2010
De-sucking Viewer 2
With the impending release of the next version of Phoenix, the team is beginning to turn its attention to Firestorm, our version of Viewer 2. We're just beginning the process, and there's a lot of work to do. Even so, there's already been significant de-sucking done, as this screenshot will show.
The biggest overall complaint is that Viewer 2 wastes immense amounts of screen space, between the sidebar and the separate IM and local chat floaters and the UI design that puts huge borders everywhere for no apparent or good reason. As that screenshot shows, we've already gotten local chat docked into the IM window, with vertical tabs, as in Phoenix, and a separate inventory floater like the one in version 1. That screenshot is already very reminiscent of the way I lay out Phoenix's user window.
This is very preliminary. We haven't really devoted much thought or design effort to Firestorm, as yet, and so any or all of that can change. We also have a lengthy list of features to examine, adapt, and port to the new codebase. The whole developer community uses Phoenix's feature set above and beyond that of the base viewer. To be sure, we all use different parts of it, but if there's a feature in Phoenix, there's a member of the team that uses and knows it.
We're not going to put out a viewer we won't use ourselves.
In addition, the members of the development team have a wide range of experience within SL, and the folks we know have an even wider range. For example, I personally know one of the biggest vendors of clothing in SL. As far as I'm concerned, Firestorm isn't ready for prime time unless he can get his job done as easily as he does today, with the minimum of learning curve to surmount. (He doesn't have time to spend learning another way of working. He's too busy creating.) The same goes for folks in many other realms of SL.
No, Firestorm isn't going to happen overnight. There's too much to de-suck, for too many people. I don't expect even an alpha version to be available to the testers for quite some time. I can promise this, though: When it does come out, it'll be worth the wait.
The biggest overall complaint is that Viewer 2 wastes immense amounts of screen space, between the sidebar and the separate IM and local chat floaters and the UI design that puts huge borders everywhere for no apparent or good reason. As that screenshot shows, we've already gotten local chat docked into the IM window, with vertical tabs, as in Phoenix, and a separate inventory floater like the one in version 1. That screenshot is already very reminiscent of the way I lay out Phoenix's user window.
This is very preliminary. We haven't really devoted much thought or design effort to Firestorm, as yet, and so any or all of that can change. We also have a lengthy list of features to examine, adapt, and port to the new codebase. The whole developer community uses Phoenix's feature set above and beyond that of the base viewer. To be sure, we all use different parts of it, but if there's a feature in Phoenix, there's a member of the team that uses and knows it.
We're not going to put out a viewer we won't use ourselves.
In addition, the members of the development team have a wide range of experience within SL, and the folks we know have an even wider range. For example, I personally know one of the biggest vendors of clothing in SL. As far as I'm concerned, Firestorm isn't ready for prime time unless he can get his job done as easily as he does today, with the minimum of learning curve to surmount. (He doesn't have time to spend learning another way of working. He's too busy creating.) The same goes for folks in many other realms of SL.
No, Firestorm isn't going to happen overnight. There's too much to de-suck, for too many people. I don't expect even an alpha version to be available to the testers for quite some time. I can promise this, though: When it does come out, it'll be worth the wait.
Subscribe to:
Posts (Atom)