Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Enabling SMIL by default (and other work-in-progress features)

2 views
Skip to first unread message

rocal...@gmail.com

unread,
Jan 15, 2009, 3:42:30 AM1/15/09
to
We've landed initial SMIL/SVG-Animations support on trunk, but it's
disabled by default in configure. I've been assuming we should only
turn it on when we think we'll be able to ship it in the next Gecko
release --- because I think that nightly builds should be as close as
possible to the feature set our apps will eventually release with. But
is that actually our policy? Should it be?

(We need to discuss the exact criteria for SMIL support to be in a
shippable state, but that's a separate discussion we'll have here
later...)

Rob

Mike Beltzner

unread,
Jan 15, 2009, 10:39:48 AM1/15/09
to rocal...@gmail.com, dev-pl...@lists.mozilla.org
On 15-Jan-09, at 3:42 AM, rob...@ocallahan.org wrote:

> We've landed initial SMIL/SVG-Animations support on trunk, but it's
> disabled by default in configure. I've been assuming we should only
> turn it on when we think we'll be able to ship it in the next Gecko
> release --- because I think that nightly builds should be as close as
> possible to the feature set our apps will eventually release with. But
> is that actually our policy? Should it be?

I don't know if we have a hard and fast policy on this, but it falls
in line with the way other features worked their way into the tree,
especially ones which may result in a performance impact. Having it
available but disabled allows developers interested in hammering out
perf and stability bugs to iterate on trunk (instead of off in a
patchset or private repo) without otherwise affecting stability.

Overall, when adding major new layout features like this, I think we
need to evaluate as a community the benefit / cost and set criteria
for when it will be turned on by default.

> (We need to discuss the exact criteria for SMIL support to be in a
> shippable state, but that's a separate discussion we'll have here
> later...)

Agreed.

Sounds like this process is going well. Might want to write a
developer.mozilla.org doc for people who want to contribute so they
know how to enable it at compile time.

cheers,
mike

Jonas Sicking

unread,
Jan 15, 2009, 4:50:06 PM1/15/09
to Mike Beltzner, rocal...@gmail.com, dev-pl...@lists.mozilla.org
Mike Beltzner wrote:
> On 15-Jan-09, at 3:42 AM, rob...@ocallahan.org wrote:
>
>> We've landed initial SMIL/SVG-Animations support on trunk, but it's
>> disabled by default in configure. I've been assuming we should only
>> turn it on when we think we'll be able to ship it in the next Gecko
>> release --- because I think that nightly builds should be as close as
>> possible to the feature set our apps will eventually release with. But
>> is that actually our policy? Should it be?
>
> I don't know if we have a hard and fast policy on this, but it falls in
> line with the way other features worked their way into the tree,
> especially ones which may result in a performance impact. Having it
> available but disabled allows developers interested in hammering out
> perf and stability bugs to iterate on trunk (instead of off in a
> patchset or private repo) without otherwise affecting stability.

So from what I understand from what Roc is saying it's disabled at a
build level. This means that only people that build themselves can turn
it on and experiment.

Having it built but configured off sounds like a great idea to me.
Possibly even a state we could ship in, though that is a separate question.

/ Jonas

Damon Sicore

unread,
Jan 16, 2009, 12:17:38 AM1/16/09
to Jonas Sicking, rocal...@gmail.com, dev-pl...@lists.mozilla.org

On Jan 15, 2009, at 1:50 PM, Jonas Sicking wrote:

> Mike Beltzner wrote:
>> On 15-Jan-09, at 3:42 AM, rob...@ocallahan.org wrote:
>>> We've landed initial SMIL/SVG-Animations support on trunk, but it's
>>> disabled by default in configure. I've been assuming we should only
>>> turn it on when we think we'll be able to ship it in the next Gecko
>>> release --- because I think that nightly builds should be as close
>>> as
>>> possible to the feature set our apps will eventually release with.
>>> But
>>> is that actually our policy? Should it be?
>> I don't know if we have a hard and fast policy on this, but it
>> falls in line with the way other features worked their way into the
>> tree, especially ones which may result in a performance impact.
>> Having it available but disabled allows developers interested in
>> hammering out perf and stability bugs to iterate on trunk (instead
>> of off in a patchset or private repo) without otherwise affecting
>> stability.
>
> So from what I understand from what Roc is saying it's disabled at a
> build level. This means that only people that build themselves can
> turn it on and experiment.

That's how I read it. Roc, is this a build time option?

>
>
> Having it built but configured off sounds like a great idea to me.
> Possibly even a state we could ship in, though that is a separate
> question.
>
> / Jonas

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Daniel Holbert

unread,
Jan 16, 2009, 1:49:22 AM1/16/09
to Damon Sicore, Jonas Sicking, rocal...@gmail.com
>> So from what I understand from what Roc is saying it's disabled at a
>> build level. This means that only people that build themselves can
>> turn it on and experiment.
>
> That's how I read it. Roc, is this a build time option?

That's correct -- it's a build-time option ("--enable-smil"), which is
currently disabled by default.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=473705 on enabling
that option by default, when it's "ready" (for whatever definition of
"ready" we decide upon).

>> Having it built but configured off sounds like a great idea to me.
>> Possibly even a state we could ship in, though that is a separate
>> question.

That seems like a good alternative... It'd definitely enable better
experimentation / testing for SMIL from the community. Roc, what do you
think about that possibility?

~Daniel

Jonas Sicking

unread,
Jan 15, 2009, 4:50:06 PM1/15/09
to Mike Beltzner, dev-pl...@lists.mozilla.org, rocal...@gmail.com
Mike Beltzner wrote:
> On 15-Jan-09, at 3:42 AM, rob...@ocallahan.org wrote:
>
>> We've landed initial SMIL/SVG-Animations support on trunk, but it's
>> disabled by default in configure. I've been assuming we should only
>> turn it on when we think we'll be able to ship it in the next Gecko
>> release --- because I think that nightly builds should be as close as
>> possible to the feature set our apps will eventually release with. But
>> is that actually our policy? Should it be?
>
> I don't know if we have a hard and fast policy on this, but it falls in
> line with the way other features worked their way into the tree,
> especially ones which may result in a performance impact. Having it
> available but disabled allows developers interested in hammering out
> perf and stability bugs to iterate on trunk (instead of off in a
> patchset or private repo) without otherwise affecting stability.

So from what I understand from what Roc is saying it's disabled at a

build level. This means that only people that build themselves can turn
it on and experiment.

Having it built but configured off sounds like a great idea to me.

Possibly even a state we could ship in, though that is a separate question.

/ Jonas

Natch

unread,
Jan 16, 2009, 11:30:49 AM1/16/09
to
CMS is disabled by default but can be enabled thorugh about:config,
why not do the same for SMIL? I've since been using CMS (with
mangement.mode set to 1) and have been very happy with it. Make a
search though bugzilla and you'll see how many bugs were uncovered and
fixed from nightly testing, IMHO this is the best option for new
exciting features that need extensive testing. Especially this early
on in (1.9.2 is still pre-alpha 1)...

sayrer

unread,
Jan 20, 2009, 12:54:06 AM1/20/09
to
On Jan 15, 3:42 am, "rob...@ocallahan.org" <rocalla...@gmail.com>
wrote:

> We've landed initial SMIL/SVG-Animations support on trunk, but it's
> disabled by default in configure. I've been assuming we should only
> turn it on when we think we'll be able to ship it in the next Gecko
> release --- because I think that nightly builds should be as close as
> possible to the feature set our apps will eventually release with. But
> is that actually our policy? Should it be?

Since we're unable to disable it at standards organization level, we
should turn it on by default in trunk nightlies, imho.

- Rob

0 new messages