Since you mention "X-Men" and "Phoenix", how about using "Dark Phoenix" as the project code name?

(From Alex: For that XUL dark matter? :-) )

I think that I'm going to have to find another cross-platform desktop solution as like you I don't have the resources for compiling against three different OSes.

Regards,

Rob...

(From Alex: I'd hope instead you'd participate in some kind of joint project like what AllPeers is proposing with MozPad.).

Rob, firstly, there are quite a few boxens out there in the Mozilla community network for doing builds like SeaMonkey, which are not official Mozilla product builds, but still exist.

Secondly, and much more important, do you really intend to ship an application on a platform that you never tested in on, not even remotely? That doesn't sound right.

(From Alex: Axel, do you want to contact Rob directly via e-mail?)

Alex,

The problem with the AllPeers efford is whether I want to "bet the company" on it long term. That all depends on how much of a fork from the Mozilla browser-specific xulrunner it becomes. i.e how easy will it be to get non-browser/internet related code into MoFo's version of xulrunner?

Having said that, I'll be watching the AllPeers effort with interest.

Regards,

Rob...

(From Alex: That's a fair concern.)

See, I didn't read that that way at all. Nothing in there says to me "we're going to stop distributing precompiled XULRunner builds from mozilla.org". All it means is that we're not going to spend the significant effort to get things into a state where XULRunner apps can use a single shared XULRunner install. I think that's pretty reasonable given the resource constraints, as well as the many unresolved issues involved.

(From Alex: I read it as "We're not going to put out a build that reads as 'official XULRunner 1.9', gone through a QA cycle and rubber-stamped as okay for general use." That's the problem.)

Alex, what exactly are you expecting QA to do?

There is exactly one xulrunner app we have, and that's "simple". Yeah, OK, QA could run that on all three platforms, but that's not QA.

Real QA would probably involve all development departments out there shipping xulrunner to take a release candidate and pipe them through their QA and testing stages, and certify or something.

This is probably part of the big versioning xulrunner and certifying compatible versions of applications vs xulrunners and the whole installation/deinstallation story.

I do have hopes for mozpad to come up with channels to actually do QA on xulrunner RCs, and once that happens, you'll see folks reevaluating statements as they are today. I guess.

Yeah, I still don't see the problem. Maybe XULRunner app developers should get some automated unit/functional tests setup, and have them report to a tinderbox so we could have more test coverage of the XUL platform as a whole, but I still don't see what that gets you. It's not like you had any of that for the 1.8.0 or 1.8.1 branch XULRunner builds, so you haven't lost anything. If anything, the situation should be better for 1.9, once SeaMonkey switches over to suiterunner, since you'll have an in-tree XULRunner app getting real testing. Honestly, if you're building a XULRunner app, and Mozilla.org is building XULRunner nightlies, then what's the problem? You can test the nightlies with your app, file/fix bugs you find, and ship whatever nightly happens to work well with your app. If anything, I would say this is a better model for you. Should you be stuck with the XULRunner build equivalent to what shipped with Firefox 3, even if it contains an unfixed bug that's a showstopper for your app? Wouldn't you rather be able to ship the next nightly that has that fix?

Axel,

I'm not worried about my testing, I just don't want to have to do the whole compile thing as I'm not set up for compiling C code on Mac(PPC), Mac(Intel), Linux and Windows. xulrunner allows me to be pretty sure that if my app works on OSX10.3, then it'll work on OSX10.4 too. Ditto with Win32/64. I'm certainly not in a position to provide all those xulrunner binaries with my hardware.

It's a little moot now anyway as I've read Benjamin's clarification.

Regards,

Rob...