Bugzilla down - Revzilla loses its mind
Bill Marriott
wjm at wjm.org
Sat Dec 23 12:19:05 EST 2006
Richard,
> 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