01 July 2013

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.


  1. All of which explains why so many of us use Firestorm.
    Nil Carborundum Illegitimi

  2. Tonya, please, be honest... CHUI is *totally* decoupled from Materials (which only impacts the render pipeline and the Face editing panel, which is not CHUI-dependent either).
    Materials can be implemented without worrying about CHUI stuff at all, but of course, it implies that your developers work from the source code and not just try and "merge commits" from LL's viewer repository in the order they come out (in that order, CHUI came first and of course you get rejects on that because of your own UI changed in FS)...

    Also, April is quite late for SSB support (I had it fully working and released in January, i.e. 3 months sooner), and should I remind you that LL initially planed to roll SSB out in February ?

    As for the time I spend on the Cool VL Viewer, it is not that large: I'm currently spending 8-10 hours a *week* on it, compilation and release process (release notes writing, HTML editing (hand-written) for my site, uploading, etc) included. Granted, there are some periods of time (during my vacations and when "big changes" are needed, like it was the case for mesh) when I spend much more time for one or two couple of weeks straight, but that's happening like once or twice a year only.
    Mind you, I do also have to work for a living...

    1. Henri, we merge commits from LL's code so that we can continue to merge into the future without having to commit ourselves from that point forward to doing things manually. The tools are there for a reason. Most of the time, they make life simpler, not harder. In a team environment, the ability to collaborate that way is priceless. As a lone developer, you don't have to worry about that.

      We had SSB ready to go about the end of February. Our other processes and QA cycles stretched that out. We also had more to fiddle with than you did.

      As for spending time on the viewer, I'm happy to hear it's not consuming your entire life. I hope that remains the case. Still, it would not take much from LL to change that. You're willing to run that risk. I am not.

  3. That's exactly what I explained on Nalate's blog: what counts is not the number of developers in a team, it's the development model... Using the wrong tools (a code repo) and method (merges, instead of a a true fork and backports), you waste your time while I work alone but much faster.
    For your info, the *only* tools I'm using to program are a text editor (nedit), and the 'grep', 'diff' and 'patch' commands.

    1. The problem is that your method won't scale. You know everything that's been done because you did it. In a collaborative environment, that won't fly: the only place the knowledge can exist is in the codebase itself.

      Also, if you get hit by the proverbial bus, your code dies. If one of us gets hit by a bus, Firestorm will continue on as before.

      Your method works for you. Our method works for us. I still think there will come a point where you have bitten off more than you can chew.

    2. And I will prove you wrong again in the future, like I already did in the past... ;-P

      In the mean time, people will judge from the facts.

    3. True. TO be clear, I admire your dedication and skill. I'm happy that there are alternatives for folks who can't use Firestorm for whatever reason. I just think you're misguided.

  4. "Niran's a programmer"

    I'm not a coder. I'm not a programmer. Which like you already said, makes no difference to me as i only know coder as the correct english word for someone doing stuff like developing a Viewer. Programmer sounds like a pathetic german-to-english translated word to me, which is the reason i dont use it. I'm just a user who needs a cutting-edge up-to-date Viewer with some functions and features from several Viewers + my own crap no other Viewer has. There are plenty of people who do share this need and there are plenty of people who dont have any stability issues with my Viewer.

    QA is always wasted...

    "...when you're working on software that's intended for someone else..."

    ...aaaand then it still doesnt work for so many users.

    "he hacks on code rather than making good software."

    I can't hack. Hacking is what LL does. Hacking is what you do. I just write pointless words into a row and hope they compile xP

    "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."

    I write pointless stuff into a row, compile it and see if it works, i dont really change anything big that could totally fuck up in a million different ways like LL's stuff usually does. My stuff is often just simple, straight things that really can't go wrong. Therefor i see no reason to have a whole group as beta testers to wait for just so i can finally release an outdated version. When i'm working on my Viewer, i constantly add or change stuff, i can't just stop and say "Ok the next 2 weeks are just for QAing", that simply wouldn't work, it would kill me because i want to add/remove and/or change things whenever i desire and i dont want to have a ten different repositories for each stupid little experiment i do... i would be more busy creating/managing repositories than actually doing stuff. A slowdown i couldnt bear.