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
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
cheers,
Armen
----- 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
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
Can we use this opportunity to say that native addons are official deprecated and we will remove them from a future release?
Doug
Mike
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
----- Original Message -----
Standard8
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