Re: Unprefixing CSS properties

On Wed, Nov 16, 2011 at 4:45 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/17/11 1:39 PM, Tab Atkins Jr. wrote:
>
>> Recognizing when a feature is ready takes more than zero time, and
>> other features can become ready before anyone notices the first.
>> Delaying by a month or two while another feature that's *nearly* ready
>> finishes stabilizing reduces the bureaucracy involved.
>>
>
> By a month or two, sure.  Our delays have tended to be measured in years...
>
> Here's a thought: can we simply "release" things on a schedule, similar to
> what some UAs are doing with their rendering engines?  Whatever is ready
> when the date rolls around gets moved to CR.  If the set is empty, it's
> empty.
>
> A 4-month cycle or something might work reasonably well.


YES! My strong preference would be to do something like this. We could use
in-spec, per-feature stability markers to mostly automate this. Every
X-months, we fork the "trunk" spec and cull the unstable features, then
spend a week or two making sure the spec is "releasable" and call that a
CR. All the rest of our time and effort goes on the "trunk" spec instead of
the "release branches".

Any spec that isn't 100% stable and can't meet this schedule is effectively
abandoned and needs a new editor. This approach has the added advantage of
letting us identify more quickly when specs are stalled and not making
progress to CR.

With this approach we spend minimal time shuffling features around between
specs, but there are also clear, versioned specs that represent the stable
feature-set.

We could at the same time, cut a branch of the entire spec for
patent-review. I'm assuming you'd want patent review on the unstable
features as well.

Ojan