Tracking LL's big changes

Ever since the release of materials in LL's viewer 3.6.0, there've been calls for us to put it in Firestorm. I'm quite receptive to the idea. Since I worked on the materials project, I know what it can do, and would love to see Firestorm get the capability to use it. I also think that it won't take off until we add it to Firestorm, just as mesh didn't take off until we added it to Phoenix.

There's a big roadblock for us, though. As I pointed out in a thread on SLUniverse:

The problem isn't that the materials code depends on the CHUI code directly. The problem is that the merge process depends heavily on code changes being applied in the same order to the same files. The CHUI changes hit a large part of the viewer codebase. (That's why it took LL a year to get CHUI out the door.) Inevitably, those changes hit files that the materials project changed. When they do, if you don't merge in the CHUI changes first, then you have to do a lot more work to fit the materials project changes into the code - work that you'll have to undo when you finally get around to putting the CHUI changes in, or will have to do over and over if you ignore the CHUI changes altogether.

This is the real reason that TPVs track the Linden viewer so closely: self-preservation. The more we diverge from the LL viewer, the harder we have to work to keep up with LL's changes.

CHUI is, for us, a big no-op in functionality. The changes are mostly duplicative of changes we put in Firestorm a long time ago, though different in design (and not particularly better, either). Still, the changes permeate the codebase, and we have to accommodate them (mostly by bypassing them with calls to our own code, but not always). This is a nontrivial exercise.

We're working on that now. We started working on it in earnest right after releasing 4.4.1. The code compiles and links and runs, but has lots and lots of bugs in it. We're working through those, one at a time, and will get it up to where we think it should be as quickly as we can. Once we do, then we can put stuff we actually want in the viewer.

Nalates Urriah pointed to my comment on her blog. Her post drew two comments, one from Henri Beauchamp and one from NiranV Dean. The two comments are worth replying to for entirely different reasons.

I've said before, and will keep saying, that I admire Henri for his efforts to keep the V1 UI interface alive in CoolVL, but I think he's fighting a losing battle. He commented,

“I told you, Tonya…” This is what I can say, seeing how the Cool VL Viewer (a v1 UI viewer that Tonya pretended would be unmaintainable in the long term, see: http://sldev.free.fr/forum/viewtopic.php?f=5&t=584#p2430) had its experimental branch with materials implemented only a couple of weeks after the code was opened by LL (and v1.26.9 is now kept exactly on par with LL’s v3.6 materials viewer), and how Firestorm lags big time behind every new feature (the Cool VL Viewer was also the first TPV with SSB, back in January 2013, while Firestorm only gained it recently.

This proves how prominent is a development model over the size of the developers team…

This is one case where Henri didn't have to worry about LL changes. The reason is in the name: CHUI is a UI-specific change, one Henri could largely, if not completely, ignore. That's a rarity in the world of SL viewer development, and he will seldom be so lucky.

Henri's incorrect when he says Firestorm got SSB capability "only recently". The initial SSB-capable Firestorm release was publicly available April 22 of this year, but the code was in the codebase much sooner, back around the end of February.

As for the difference in development models, it's obvious that Henri spends a large amount of time on his viewer, more so than any individual member of the Firestorm team. Again, that's admirable, but I still have my doubts as to how sustainable it is over the long run.

Niran's comment is more revealing:

Just keep in mind that a total retard like me is faster in implementing Materials and SSB and keeping up with LL while still doing heavy UI modifications than Firestorm. Mostly because i dont have a freaking huge Viewer with millions of features to maintain… and because i dont do 2 weeks QA. 2 weeks QA are 2 wasted weeks in which i could have collected a week worth of bugreports, fixed them, worked more on other stuff, make a release, collect bugreports and feedback on that one and, fixed stuff, work even more on other things and update a second time.

"I don't do 2 weeks QA." That says it all right there. Niran's viewer doesn't get any QA, as far as anyone can tell. He slaps it together, tests it himself for some minimal period of time, and throws it out to the world.

QA is never wasted when you're working on software that's intended for someone else, never mind a lot of someone elses, to use. That he derides it as he does shows hos true mindset: he hacks on code rather than making good software.

Niran's a programmer, not a developer of production-quality software. He has no understanding of the difference. That's fine for him and his users, but the average user would much rather have a viewer that is actually likely to work well and stably rather than have the absolute newest shinies. You get there by moving more slowly and carefully than Niran does, actually working to integrate patches form others instead of just dropping them in, and actually doing meaningful QA with more than just one or two testers.

The Firestorm team does what it does the way it does it for good, sound reasons. I think the proof of how well we succeed at it is in the viewer we put out.