Bugzilla down - Revzilla loses its mind

Bill Marriott wjm at wjm.org
Sat Dec 23 12:19:05 EST 2006


> Any interface is an interface, whether it be PHP/HTML/JavaScript or 
> Revolution.  Both are separate from the underlying storage of the data 
> they present, and when the business logic of the data store changes then 
> of course any UI used to present that data will need to keep in step with 
> it.

Yes, an interface is an interface... and they are indeed separate from the 
underlying data storage.

The part of *your* idea that needs clarifying is the non-trivial difference 
in delivery to end users. When Marcus and I were working on the UI of the 
new system, he'd update the web page and I'd press F5 to see the change 
instantly. We could very interactively build the system, trying out 
different ideas effortlessly. If it were instead a stack, the process would 
be far more involved.

Now extend this to a large population of end users. It's just unacceptable 
to have a new "software update" going out every day or possibly even several 
times a day to customers. Yet that is what could easily happen (or be 
required) in a scenario where the QC was being worked on. We fix a typo... 
new update required. We add a field... new update required. We add a help 
page... new update required. And don't forget that you would not be 
supporting TWO interfaces (since you agree the Web one couldn't be avoided).

When Marcus gets back from his vacation, I plan to send him a new GIF for 
the title bar that pushes the logo/text down a couple pixels. That's a 
4-second effort on his part to just replace the image on the server and zero 
impact to end users. There was no need to invent the mechanism to do that; 
no need to test or debug it; no version control overhead. It just works. 
Hard to get much easier than that.

So the question is not the separation model, but rather the 
delivery/maintenance challenge. The added time/difficulty associated with 
those shouldn't be glossed over.

> I don't think anyone's ever advocated ditching the web UI for the 
> database, but as long as Revzilla is appreciated at RunRev why not just 
> bundle it in the Plugins folder?

This sounds a little bit like a well-meaning aunt saying, "Oh, such a cute 
couple! When are you two getting married?" :)

I don't think that Rev is "refusing" to do so. But this suggestion makes a 
lot of assumptions, not the least of which is whether Ken himself would 
prefer it distributed this way, whether he's unhappy with the current setup, 
etc. I also don't think it should be assumed to be free. Keeping a client 
program updated with the server is no easy undertaking. And isn't it a 
little weird to be talking about it as if Ken (and RunRev) weren't in the 
room? I suggest that we take this part of the discussion backchannel.

Sure there's a lot more that COULD be done with Bugzilla/Quality Control 
Center. But it's my hope that we've made the reporting tool much better --  
more than good enough, now -- and can now direct those resources to other 
things that desperately need attention like the Installer, documentation ... 
and the bugs reports themselves (updating their status, etc.). 

More information about the Use-livecode mailing list