Discussion:
[CSS2] Proposed process for maintaining CSS2
(too old to reply)
fantasai
2016-12-02 01:26:52 UTC
Permalink
Raw Message
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
Florian Rivoal
2016-12-02 07:14:57 UTC
Permalink
Raw Message
Post by fantasai
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).
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
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".
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.
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.
Push A to CSS2.1 PER, then REC once that times out.
Push B to perpetual WD CSS2.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
Alan Stearns
2017-02-01 20:07:18 UTC
Permalink
Raw Message
We’ve had several conversations about CSS2 maintenance recently. I’ve added a summary of the current state of the proposal to the wiki:

https://wiki.csswg.org/spec/rec-maintenance

Please use this thread to discuss any changes or clarifications we may need to make.

Thanks,
Liam R. E. Quin
2017-02-02 01:18:44 UTC
Permalink
Raw Message
Post by Alan Stearns
We’ve had several conversations about CSS2 maintenance recently. I’ve
https://wiki.csswg.org/spec/rec-maintenance
Please use this thread to discuss any changes or clarifications we may need to make.
Did you mean "this email thread" or "this wiki thread"?

Well, either way, I added to the Wiki a note about the more usual
approach of publishing a proposed edited recommendation (PER), which is
just a candidate rec entitled PER, and which can be republished as a
PER if there are substantive changes.
Post by Alan Stearns
Thanks,
Alan
Alan Stearns
2017-02-02 03:54:21 UTC
Permalink
Raw Message
Post by Liam R. E. Quin
Post by Alan Stearns
We’ve had several conversations about CSS2 maintenance recently. I’ve
https://wiki.csswg.org/spec/rec-maintenance
Please use this thread to discuss any changes or clarifications we may need to make.
Did you mean "this email thread" or "this wiki thread"?
Well, either way, I added to the Wiki a note about the more usual
approach of publishing a proposed edited recommendation (PER), which is
just a candidate rec entitled PER, and which can be republished as a
PER if there are substantive changes.
I meant the thread here, but capturing the discussion on the wiki is good, too. For those following along here, I added this response:

This is the method we want to use in the proposal below for those changes we know are ready for a quick CR. When we're not sure which changes will survive review and/or be adopted and testable, the problem is that the REC gets stuck in a republished CR cycle. I don't think it's good to take a REC back to CR for changes that haven't yet been vetted.

Thank
Liam R. E. Quin
2017-02-02 04:30:57 UTC
Permalink
Raw Message
[...]
Post by Alan Stearns
This is the method we want to use in the proposal below for those
changes we know are ready for a quick CR. When we're not sure which
changes will survive review and/or be adopted and testable, the
problem is that the REC gets stuck in a republished CR cycle. I don't
think it's good to take a REC back to CR for changes that haven't yet
been vetted.
To be clear, there's no question of "taking a rec back to cr" at all.

The Recommendation stays as a recommendation unless the WG decides to
rescind it. You just get a time when there's a Rec and *also* a
proposed edited rec (or whatever) on /TR.

If you want people to review the changes and comment you have to accept
that yes, they might want changes that result in a republished CR, but
this isn't harder than republishing a working draft these days -
there's no transition call to go through or anything.

Under that process we'd presumably end up with CSS 2.2 Second Edition.

At any rate I'm not trying to push one method or another so much as to
make sure the options are made available for consideration.

Thanks

Liam
Post by Alan Stearns
Thanks,
Alan
Florian Rivoal
2017-02-02 04:57:47 UTC
Permalink
Raw Message
Post by Liam R. E. Quin
[...]
Post by Alan Stearns
This is the method we want to use in the proposal below for those
changes we know are ready for a quick CR. When we're not sure which
changes will survive review and/or be adopted and testable, the
problem is that the REC gets stuck in a republished CR cycle. I don't
think it's good to take a REC back to CR for changes that haven't yet
been vetted.
To be clear, there's no question of "taking a rec back to cr" at all.
The Recommendation stays as a recommendation unless the WG decides to
rescind it. You just get a time when there's a Rec and *also* a
proposed edited rec (or whatever) on /TR.
If you want people to review the changes and comment you have to accept
that yes, they might want changes that result in a republished CR, but
this isn't harder than republishing a working draft these days -
there's no transition call to go through or anything.
Under that process we'd presumably end up with CSS 2.2 Second Edition.
We could do that, but the problem is that we kind of know for sure that
some edits aren't ready. Presumably they will be eventually, but that could
take a fairly long time.

In the meanwhile we'll have an outdated REC, and a not-a-REC document with
some REC quality changes, and some uncertain changes. While the end result
would be the same, the long transition period would leave us with no good
way to point people to a document that is "CSS2, all the things we're sure
about".

The proposed process is an attempt at having the ability to get the fully baked
changes to graduate to REC while the rest is still cooking.

From an editorial point of view, we could probably just have an ED with everything,
an ED with just the things we know are good enough for REC already, and cycle via
CR/PR/REC on based on that second ED. The only problem that this leaves us is
that there would not be any document on w3.org that would reflect the latest thinking
on CSS2. The point of the Note was to have that space on w3.org where we could call
for reviews. Partly because the process calls for it, partly because reviews are good.

This Note would effectively be a working draft in the plain english sense, as it's the
draft we work with, but it would not be a Working Draft in the Process sense,
as it is not a document we intend to move along the REC track. We intent to cherry
pick things from it, and put them into another document, that one being intended to
move on the REC track.

I think the workflow we discussed in Seattle is somewhat unusual, but seems to be about
as good as it gets with the current tools and Process, so I think we should go ahead with
it.

At the same time, it is a bit odd, and living-standard / REC-track document pairs
face the same issues, so it would be good for the AB to look into streamlining that.

— Florian
Liam R. E. Quin
2017-02-02 05:59:06 UTC
Permalink
Raw Message
Post by Florian Rivoal
We could do that, but the problem is that we kind of know for sure that
some edits aren't ready. Presumably they will be eventually, but that could
take a fairly long time.
So make a 3rd edition when they're ready. In the meantime include (in
the document) notes on the areas that aren't ready that point to an ED?
Post by Florian Rivoal
This Note would effectively be a working draft in the plain english sense, as it's the
draft we work with, but it would not be a Working Draft in the
Process sense,
as it is not a document we intend to move along the REC track.
I'd be much happier seeing it be on the rec track so that patent
commitments apply.

Thanks for replying. Maybe if I'd been able to go to Seattle I'd be OK
with this, but as it is I'm trying to see if we can't use the existing
Process a little more efficiently.

Liam
Florian Rivoal
2017-02-02 07:10:28 UTC
Permalink
Raw Message
Post by Liam R. E. Quin
Post by Florian Rivoal
We could do that, but the problem is that we kind of know for sure that
some edits aren't ready. Presumably they will be eventually, but that could
take a fairly long time.
So make a 3rd edition when they're ready. In the meantime include (in
the document) notes on the areas that aren't ready that point to an ED?
This is a partly orthogonal question:
* do we keep on updating CSS2.1, or do we create CSS2.2, CSS2.3...
* How do we prepare the changes that go into the next thing that's going to REC (regardless of how we call it) vs those that are still brewing.

My previous comment only addressed the second point.

As to the first one, we do not wish to teach people and search engines about the existence of a new CSS 2, separate from CSS2.1. Once the new REC is out, nobody should ever need to refer to what we currently call CSS2.1, since this is just about rolling in errata (and doing so inline), not adding new things.

Links form all over the place, including search engine results, point to https://www.w3.org/TR/CSS21/, and people know it under that name. There's no benefit to trying to teach the whole world to now ignore it and talk about CSS2.2 everytime they mean CSS2.1.

The delta between the thing we're preparing and current CSS2.1 is also very different from the delta between CSS2.0 and CSS2.1. That was a significant change in scope and functionality. In this case we are only talking about inlining erratas. Using the same numbering scheme for both updates would be misleading.
Post by Liam R. E. Quin
Post by Florian Rivoal
This Note would effectively be a working draft in the plain english sense, as it's the
draft we work with, but it would not be a Working Draft in the Process sense,
as it is not a document we intend to move along the REC track.
I'd be much happier seeing it be on the rec track so that patent
commitments apply.
This is only about errata. There is no new features. We've already got all the patent commitment in the existing REC. And even if we assume that some substantive errata may change the behavior enough that patent coverage would be impacted, then it makes it all the more important to have a process that reaches REC quickly. The goal of this process is to be able get changes that are ready to REC as fast as possible, potentially issuing multiple REC updates to CSS2.1 per year.
Post by Liam R. E. Quin
Thanks for replying. Maybe if I'd been able to go to Seattle I'd be OK
with this, but as it is I'm trying to see if we can't use the existing
Process a little more efficiently.
Yes, this is a little nasty, but this is the best we could come up with. The process process is fine for doing new documents and getting them to REC including when the new documents supersede some previous RECs, but it doesn't seem to have a convenient way of doing in-place maintenance on existing RECs other than diff-like errata in a separate document, which are bad, because they mostly unnoticed, and even when you know about them, are hard to read.

If you haven't done so yet, I suggest looking at the Seattle minutes about that.

—Florian
Geoffrey Sneddon
2017-05-09 00:55:59 UTC
Permalink
Raw Message
Post by Alan Stearns
https://wiki.csswg.org/spec/rec-maintenance
Please use this thread to discuss any changes or clarifications we may need to make.
I discussed a bunch of things around the CSS2 maintenance story with
plh today; I'll let him correct me if I mis-summarise him!

I believe he views "We want a draft with changes in-line for review
published on TR" as a goal we don't need: while we need to have "wide
review", we don't need a document in TR-space for this. We're strictly
making this harder for ourselves than we need to. We can just get the
wide-review done on the editor's draft (or, even, from the Director's
viewpoint, on the errata document itself!).

As such, his suggestion is that we just take the two-ED route and do that.

I'll also point out the wiki page has a paragraph beginning with
"Another option, and I think more usual, is to issue a Proposed Edited
Rec", but PERs don't exist under the 2017 Process, which from this
thread I believe is from Liam?

/g
David Singer
2017-05-09 18:32:57 UTC
Permalink
Raw Message
Post by Geoffrey Sneddon
Post by Alan Stearns
https://wiki.csswg.org/spec/rec-maintenance
Please use this thread to discuss any changes or clarifications we may need to make.
I discussed a bunch of things around the CSS2 maintenance story with
plh today; I'll let him correct me if I mis-summarise him!
I believe he views "We want a draft with changes in-line for review
published on TR" as a goal we don't need: while we need to have "wide
review", we don't need a document in TR-space for this. We're strictly
making this harder for ourselves than we need to. We can just get the
wide-review done on the editor's draft (or, even, from the Director's
viewpoint, on the errata document itself!).
As such, his suggestion is that we just take the two-ED route and do that.
I'll also point out the wiki page has a paragraph beginning with
"Another option, and I think more usual, is to issue a Proposed Edited
Rec", but PERs don't exist under the 2017 Process, which from this
thread I believe is from Liam?
um, I think ‘edited recommendation’ exists, and it goes through a ‘proposed’ stage

<https://www.w3.org/2017/Process-20170301/#rec-edited>


David Singer
Manager, Software Standards, Apple Inc.
Geoffrey Sneddon
2017-05-25 10:13:45 UTC
Permalink
Raw Message
Post by David Singer
Post by Geoffrey Sneddon
Post by Alan Stearns
https://wiki.csswg.org/spec/rec-maintenance
Please use this thread to discuss any changes or clarifications we may need to make.
I discussed a bunch of things around the CSS2 maintenance story with
plh today; I'll let him correct me if I mis-summarise him!
I believe he views "We want a draft with changes in-line for review
published on TR" as a goal we don't need: while we need to have "wide
review", we don't need a document in TR-space for this. We're strictly
making this harder for ourselves than we need to. We can just get the
wide-review done on the editor's draft (or, even, from the Director's
viewpoint, on the errata document itself!).
As such, his suggestion is that we just take the two-ED route and do that.
I'll also point out the wiki page has a paragraph beginning with
"Another option, and I think more usual, is to issue a Proposed Edited
Rec", but PERs don't exist under the 2017 Process, which from this
thread I believe is from Liam?
um, I think ‘edited recommendation’ exists, and it goes through a ‘proposed’ stage
<https://www.w3.org/2017/Process-20170301/#rec-edited>
We still have this name of "Edited Recommendation", but we don't have
a different process for it any more: there's no stage of Proposed
Edited Recommendation any more—they either are directly published as
an Edited Recommendation (if editorial only) or go through the normal
Candidate Recommendation and Proposed Recommendation phases (with no
differences).

/g

Loading...