W3C home > Mailing lists > Public > www-style@w3.org > December 2016

Re: [CSS2] Proposed process for maintaining CSS2

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 2 Dec 2016 16:14:57 +0900
Cc: "www-style@w3.org" <www-style@w3.org>
Message-Id: <32CB9247-EC3D-490A-A433-DEA88E32210D@rivoal.net>
To: fantasai <fantasai.lists@inkedblade.net>

> On Dec 2, 2016, at 10:26, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> Thanks to Bert's recent efforts to get CSS2 updated on /TR (where
> it ought to be up-to-date), the CSSWG ended up briefly discussing
> the process for handling this, and I've been tasked with writing
> up a proposal. :)
> 
> The fundamental limitation we're working with is that any update
> to a REC must be proven to have satisfied the CR exit criteria.
> Which is totally fair, but the fact is we have some changes we
> need to make to CSS2 that qualify (e.g. changes to align with
> implementations, certain clarifications) and others that don't
> (e.g. clarifications where we don't have interop yet, or
> deliberate changes we've agreed to but haven't implemented yet).
> 
> What this means is that we need to maintain two copies of the spec:
> one which incorporates all errata that are agreed to, and one which
> cherry-picks only the errata that have two implementations at the
> moment.  So, conceptually we have a development branch and a release
> branch and changes are individually ported from one to the other
> once they pass tests, run through alpha (WG review), beta (the AC
> approval one-month delay), and final release (REC).
> 
> The rough and extremely outdated approximation of this is CSS2.1
> REC and the CSS2.2 draft. What we need to do is have a way to
> actually push the updates to CSS2.1 REC. I see two ways of doing
> this within the W3C Process:
> 
>  Method 1:
>    Periodically republish the two-implementations version of
>      CSS2.1 as PER and have the AC approve it back to REC.
>    Keep the WD of CSS2.2 updated as a perpetual "CSS2.1.Next".
> 
>  Method 2:
>    Publish the current two-implementations version of CSS2 as
>      CSS2.Next WD, and publish the current aspirational version
>      as CSS2.Next+1.
>    Once the WG has had a chance to review the CSS2.Next WD,
>      and any resulting changes are made, transition CSS2.Next
>      straight to PR and have the AC approve it as CSS2.Next REC.
>      At the time it is published as REC, rescind the previous
>      CSS2.Next-1.
> 
> The advantage of Method 2 is that we can maintain on /TR all of
> our latest work: Method 1, which we've been using, doesn't have
> an official place to store the "two-implementations" branch during
> the alpha (review) process. But I've no strong opinion on these.
> 
> To implement this, we need to maintain two editors' drafts for
> sourcing these publications. For simplicity, and because we won't
> be maintaining more than one of each type on /TR simultaneously
> anyway, I'm recommending that these be continuously maintained as
> abstract "two-implementations" and "aspirational" sources, rather
> than split to match the /TR numbering, whatever that is. The /TR
> copies should effectively mirror whatever is in the EDs--since each
> change is WG-approved, there shouldn't be much lag in publication.
> 
> We'll also need implementation reports for the "two-implementations"
> copy, and I think to help reviewers (implementers, the CSSWG
> community, and the W3C staff and AC) focus on the changes (which
> is what we care about atm, since the rest is already in REC),
> information about the tests for each change and their implementation
> status should be collated in the changes list. I'm pretty sure Bert
> and plinss can coordinate on making that painless, provided the
> tests are marked both against their originating section and the
> change's fragID.
> 
> So, brief summary:
>  * Maintain two source EDs:
>      A: All resolved changes to CSS2
>      B: Only resolved changes that have tests and two passing impls
> 
>  * B must collate tests and implementation reports together with
>    errata for easy verification of CR exit criteria.
>    A should also do this so we know when to port a change to B.
> 
>  * Publish the source EDs on /TR according to either Method 1 or 2.
>      Method 1:
>          Push A to CSS2.1 PER, then REC once that times out.
>          Push B to perpetual WD CSS2.2.
>      Method 2:
>          Push A to CSS2.Next WD (alpha).
>          Push B to CSS2.Next+1 WD (nightly).
>          Once WG approves CSS.Next alpha, transition to PR (beta).
>          Once AC approves CSS.Next beta
>            * Transition CSS.Next beta to REC (final).
>            * Rescind or otherwise obsolete CSS.Next-1.
>            * Purge changes lists in A and B to rebase off new REC.
>            * Republish source B as latest CSS.Next+1 WD.
>            * Republish source A as new CSS.Next+2 WD.
>          Repeat.

I suppose the definitions of A and B in the above should be inverted, but other than that, I agree, and prefer method 2.

Just one question, the answer to which doesn't change my approval of your idea: CSS2.Next certainly needs a WD (and an ED to support it), but for CSS2.Next+1, can't we get by just with an ED, to save some busywork publishing the WDs?

—Florian
Received on Friday, 2 December 2016 07:15:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 December 2016 07:15:37 UTC