Move Gecko SDK builds to main tree?

30 views
Skip to first unread message

Kyle Huey

unread,
Jul 12, 2011, 1:50:47 PM7/12/11
to dev-tree-...@lists.mozilla.org
The Gecko SDK, needed for building binary addons against Firefox, is built
as part of the XULRunner builds that run nightly. The results of these
builds end up on the XULRunner tree, where hardly anyone ever looks at
them. When we break the SDK it's generally some time before anybody notices
and files a bug. This is especially problematic with the rapid release
cycle, where not noticing the bustage for a couple weeks brings us that much
closer to needed aurora or beta approval to fix the bustage and eats into
the limited time addon makers have to make their addons compatible.

In https://bugzilla.mozilla.org/show_bug.cgi?id=661910#c35 Armen proposed
moving the XULRunner nightly builds to the main tree so that this bustage is
visible. Does anyone object to doing that?

- Kyle

Ehsan Akhgari

unread,
Jul 12, 2011, 2:17:33 PM7/12/11
to Kyle Huey, dev-tree-...@lists.mozilla.org

We don't run tests on these builds, right?

Before we decide to make these tests visible on m-{a,b,c,i}/try, we
should first answer this question: what happens if a push breaks the
SDK? Should it be backed out? Or can the bustage be tolerated? Given
the fact that XULRunner is not a tier-1 platform, I'm assuming that
bustages will not require a backout, which would mean that the builds
could continue to burn for weeks, before somebody goes ahead and hides
them. :/

Ehsan

Armen Zambrano Gasparnian

unread,
Jul 12, 2011, 2:35:04 PM7/12/11
to Ehsan Akhgari, Kyle Huey, dev-tree-...@lists.mozilla.org
I assume the expected behaviour would be to file a bug and someone to
fix it eventually, no?
I don't think backing out would be the expected behaviour as it is not
tier-1 but just filing a bug and poke whoever is the owner should do.
What we want to avoid is going blind for weeks until someone reports it.

cheers,
Armen

Armen Zambrano Gasparnian

unread,
Jul 12, 2011, 2:35:04 PM7/12/11
to Ehsan Akhgari, Kyle Huey, dev-tree-...@lists.mozilla.org
On 11-07-12 2:17 PM, Ehsan Akhgari wrote:

Mark Finkle

unread,
Jul 12, 2011, 3:47:45 PM7/12/11
to Ehsan Akhgari, Kyle Huey, dev-tree-...@lists.mozilla.org
As Kyle mentions, the SDK is used by add-on developers who need create binary libraries. In that sense the SDK is supporting a critical feature of a tier 1 product. I don't think fixing a burning build is too much to ask. Fixing a bunch of orange tests would be a stretch for the SDK.

----- Original Message -----


On 11-07-12 1:50 PM, Kyle Huey wrote:
> The Gecko SDK, needed for building binary addons against Firefox, is built
> as part of the XULRunner builds that run nightly. The results of these
> builds end up on the XULRunner tree, where hardly anyone ever looks at
> them. When we break the SDK it's generally some time before anybody notices
> and files a bug. This is especially problematic with the rapid release
> cycle, where not noticing the bustage for a couple weeks brings us that much
> closer to needed aurora or beta approval to fix the bustage and eats into
> the limited time addon makers have to make their addons compatible.
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=661910#c35 Armen proposed
> moving the XULRunner nightly builds to the main tree so that this bustage is
> visible. Does anyone object to doing that?

We don't run tests on these builds, right?

Before we decide to make these tests visible on m-{a,b,c,i}/try, we
should first answer this question: what happens if a push breaks the
SDK? Should it be backed out? Or can the bustage be tolerated? Given
the fact that XULRunner is not a tier-1 platform, I'm assuming that
bustages will not require a backout, which would mean that the builds
could continue to burn for weeks, before somebody goes ahead and hides
them. :/

Ehsan
_______________________________________________
dev-tree-management mailing list
dev-tree-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tree-management

Mike Hommey

unread,
Jul 12, 2011, 5:10:47 PM7/12/11
to Mark Finkle, Ehsan Akhgari, Kyle Huey, dev-tree-...@lists.mozilla.org
On Tue, Jul 12, 2011 at 12:47:45PM -0700, Mark Finkle wrote:
> As Kyle mentions, the SDK is used by add-on developers who need create binary libraries. In that sense the SDK is supporting a critical feature of a tier 1 product. I don't think fixing a burning build is too much to ask. Fixing a bunch of orange tests would be a stretch for the SDK.
>

Or... why don't we build the sdk as part of building Firefox?
Most of the necessary rules are in packager.mk, which is shared.

Mike

Doug Turner

unread,
Jul 12, 2011, 6:26:50 PM7/12/11
to Mike Hommey, Mark Finkle, Ehsan Akhgari, Kyle Huey, dev-tree-...@lists.mozilla.org

I thought we were going to deprecate native addons at some point 'soonish'. I am in favor of that direction, and feel that building the native SDK as part of Firefox sends the wrong signal.

Can we use this opportunity to say that native addons are official deprecated and we will remove them from a future release?

Doug

Mike

Mark Banner

unread,
Jul 12, 2011, 11:48:36 PM7/12/11
to
On 12/07/2011 15:26, Doug Turner wrote:
>
> I thought we were going to deprecate native addons at some point 'soonish'. I am in favor of that direction, and feel that building the native SDK as part of Firefox sends the wrong signal.
>
> Can we use this opportunity to say that native addons are official deprecated and we will remove them from a future release?

That's definitely not been my impression of the discussions.

I've read that binary add-ons are still supported but you're going to
have to recompile for each release.

I haven't read anywhere (or even felt it implied) that we're going to
stop having binary add-ons - its just that it will be harder for binary
add-on developers.

Standard8

Mark Finkle

unread,
Jul 13, 2011, 1:19:05 AM7/13/11
to Mark Banner, dev-tree-...@lists.mozilla.org
I agree with Mark here. There has been some blog posts from add-on developers saying the 6 week recompile will make it harder to use binary extensions, but Mozilla has not deprecated them.

----- Original Message -----

Standard8

Ben Hearsum

unread,
Jul 19, 2011, 10:51:36 AM7/19/11
to Mike Hommey, Benjamin Smedberg, Ehsan Akhgari, Kyle Huey
On 07/19/11 10:43 AM, Mike Hommey wrote:
> On Tue, Jul 19, 2011 at 10:17:14AM -0400, Benjamin Smedberg wrote:
>> Mike's suggestion in this thread to build the SDK from the Firefox
>> build instead of the XULRunner build is righteous. Someone should do
>> that! ;-)
>
> That would be a releng matter, since our build system has everything
> necessary for that.
>
> Mike

RelEng is involved, but not completely on the hook. Before we can do
anything, we need to know what extra commands we need to run as part of
the Firefox build to make this happen. At the very least, some
adjustments to the upload rules will need to happen, because they don't
support multiple products at the moment. I'm not sure how we can run
'make package' for XULRunner, either, because the mozconfig used will
have Firefox values set....

So, that's a long way of saying that we need a demonstrated build
process before we can automate it.

- Ben

Reply all
Reply to author
Forward
0 new messages