[CSS2] Proposed process for maintaining CSS2

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.

~fantasai

Received on Friday, 2 December 2016 01:27:43 UTC