XULRunner 1.9.1 nightly builds
Samuel Sidler
I tried to get this into the Platform meeting, but it got skipped and
then the meeting ended abruptly...
One of the things we've been missing for 1.9.1 is XULRunner. Add-on
developers need XULRunner and the SDK so that they can developer
binary add-ons. This has been on the back-burner of the release
engineering team's priorities, but the closer we get to Firefox 3.5's
release, the more we need XULRunner builds.
I'd like to get that bug out from "Release Engineering: Future" (I can
do that myself, but probably shouldn't) and into a "next" queue so we
can get XULRunner builds for at least 1.9.1 (hopefully mozilla-central
as well) in the next couple of weeks.
https://bugzilla.mozilla.org/show_bug.cgi?id=445191
Doing this might put other release engineering work on hold (catlee
mentioned unittests on packaged builds), but I think that's a fair
tradeoff given how close we're getting to release.
Any thoughts people have on this are more than welcome.
-Sam
Mike Beltzner
> One of the things we've been missing for 1.9.1 is XULRunner. Add-on
> developers need XULRunner and the SDK so that they can developer
> binary add-ons. This has been on the back-burner of the release
> engineering team's priorities, but the closer we get to Firefox
> 3.5's release, the more we need XULRunner builds.
They can't build these sorts of things using Firefox itself as a
runtime?
> I'd like to get that bug out from "Release Engineering: Future" (I
> can do that myself, but probably shouldn't) and into a "next" queue
> so we can get XULRunner builds for at least 1.9.1 (hopefully mozilla-
> central as well) in the next couple of weeks.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=445191
>
> Doing this might put other release engineering work on hold (catlee
> mentioned unittests on packaged builds), but I think that's a fair
> tradeoff given how close we're getting to release.
I'm not sure I agree. Performing unit test suites on packaged builds
means that we can do a unittest run independent of a build, which
promises to drastically improve our checkin -> unit test results, as
well as allows us to simply add boxes with different hardware/OS
combinations and get unit test runs on them (think Windows 7 and OSX
10.4 on PPC). That's a pretty big win no matter where we are in the
cycle.
What's the critical path / holdup on XULRunner builds?
cheers,
mike
Mike Shaver
>> I'd like to get that bug out from "Release Engineering: Future" (I can do
>> that myself, but probably shouldn't) and into a "next" queue so we can get
Can we not do manual builds of XULRunner for 1.9.1 to match FF3.5b4?
That will give us extension authors the link target they need, and
might be a fair bit cheaper than setting up automation in this
timeframe.
Mike
Dave Townsend
> On 24-Mar-09, at 3:16 PM, Samuel Sidler wrote:
>
>> One of the things we've been missing for 1.9.1 is XULRunner. Add-on
>> developers need XULRunner and the SDK so that they can developer
>> binary add-ons. This has been on the back-burner of the release
>> engineering team's priorities, but the closer we get to Firefox 3.5's
>> release, the more we need XULRunner builds.
>
> They can't build these sorts of things using Firefox itself as a runtime?
Not generally no, the SDK contains the headers and libraries to link
against that Firefox does not.
>> I'd like to get that bug out from "Release Engineering: Future" (I can
>> do that myself, but probably shouldn't) and into a "next" queue so we
>> can get XULRunner builds for at least 1.9.1 (hopefully mozilla-central
>> as well) in the next couple of weeks.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=445191
>>
>> Doing this might put other release engineering work on hold (catlee
>> mentioned unittests on packaged builds), but I think that's a fair
>> tradeoff given how close we're getting to release.
>
> I'm not sure I agree. Performing unit test suites on packaged builds
> means that we can do a unittest run independent of a build, which
> promises to drastically improve our checkin -> unit test results, as
> well as allows us to simply add boxes with different hardware/OS
> combinations and get unit test runs on them (think Windows 7 and OSX
> 10.4 on PPC). That's a pretty big win no matter where we are in the cycle.
Personally I don't think that this is critical for the 1.9.1 release,
whereas giving extensions developers what they need to develop their
extensions should be.
> What's the critical path / holdup on XULRunner builds?
That one bug, basically doing some buildbot configuration and probably
writing some code to handle uploading the sdk packages.
Dave Townsend
If we want to avoid placing an undue burden on add-on authors we would
need to try to do this on machines as closely resembling the reference
platforms as possible.
Honestly I don't think there is that much work to be done here to cause
much of a delay. I'd probably volunteer to do it myself except that the
build and release team could get it done far faster as they have access
to servers and slaves to test with.
Mike Shaver
> Honestly I don't think there is that much work to be done here to cause much
> of a delay. I'd probably volunteer to do it myself except that the build and
> release team could get it done far faster as they have access to servers and
> slaves to test with.
Let's get you that access, then?
Mike
Mark Finkle
I have done that once and plan to do it again. I was not able to get
the universal SDK built for Mac - Intel only.
http://starkravingfinkle.org/blog/2009/01/unofficial-xulrunner-191-builds/
I am disappointed that this bug has been completely dormant for so
long.
Dave Townsend
Here are 1.9.1b3 builds of XULRunner for all platforms:
http://tinyurl.com/dkqyms