(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
> 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
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
> 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
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
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
Since we're unable to disable it at standards organization level, we
should turn it on by default in trunk nightlies, imho.
- Rob