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

Re: [CSS2] Proposed process for maintaining CSS2

From: Geoffrey Sneddon <me@gsnedders.com>
Date: Mon, 19 Dec 2016 17:15:54 +0000
To: www-style@w3.org
Message-ID: <82492414-be5f-236d-41e7-222289038dd8@gsnedders.com>
So having managed to accidentally end up asking about this on IRC having
missed this a fortnight ago…

On 02/12/16 01:26, fantasai 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).

My understanding is there's no hard-and-fast rule for two
implementations of each errata for a PER, though obviously that depends
on the specific case and what the Director can be convinced of.

Speaking to plh, my impression is a lot depends on: a) whether everyone
agrees the current spec is broken, b) whether everyone agrees the change
makes sense, c) whether all implementers intend on implementing it, d)
how many implementers have already implemented it.

As such, that should reduce the changes in the alpha.

As for the schedule, I'm pretty sure we need to go to CR before PR as we
have substantive changes (i.e., non-editorial ones), and the CR entry
requirements include a requirement to show wide review prior the CR
publication. We then need a deadline for comments on the CR four weeks
or more after publication. After that we then progress to PR, and then
we have the 28 days AC review. This means the beta needs to be at least
two months, I think?

> 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".

Is there any reason why we can't call the WD "CSS 2.1 5th Edition"?
Having something called "CSS 2.2" that then becomes "CSS 2.1" is
confusing as hell to me. There's nothing stopping us from calling the
WD/CR/PER as such, is there?

> 
>   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'm strongly in favour of method 1, but without calling *anything* 2.2.
Keeping everything called 2.1 makes it *very* clear that it is the
version of 2.1 they should be looking at, and clarifies the questions
Greg was asking on GitHub about maintaining testsuites. (IMO, it makes
absolutely no sense to maintain a 2.1 and a 2.2 testsuite as we actively
*do not want* people to implement 2.1.)

/gsnedders
Received on Monday, 19 December 2016 17:16:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC