Re: Evergreen Formal Objection handling (ESFO)

> On Mar 20, 2019, at 22:23 , Jeff Jaffe <jeff@w3.org> wrote:
> 
> 
> On 3/20/2019 6:17 PM, fantasai wrote:
>> On 3/20/19 10:41 AM, Chris Wilson wrote:
>>> On Wed, Mar 20, 2019 at 10:37 AM Michael Champion <Michael.Champion@microsoft.com <mailto:Michael.Champion@microsoft.com>> wrote:
>>> 
>>>      > "Current work" in that model is a bunch of unmerged pull-requests,
>>>     Unmerged pull requests don't have "truth" status.  Active participants in spec development have
>>>     to look at the unmerged PRs, sure, but implementers/website developers/framework developers/etc
>>>     don’t need to, do they?
>>> 
>>> +1 to this.  Once there's sufficient belief that it represents consensus and is error-free (determinations a WG could decide their own rules for), they would get merged. I should have said "current truth" rather than "current work".
>> 
>> For a spec to be REC-level, it needs
>>   a) consensus under wide review
>>   b) tests
>>   c) two implementations
>> 
>> I don't imagine that an Evergreen Recommendation would be any different,
>> therefore each change as it goes in must have all of the above.
> 
> Indeed for ERs, we require:
> 
> a) A marking that a feature has had sufficient time (180 days) for wide review
> 
> b) ???  Do we need to add anything to indicate tests?
> 
> c) A marking that a feature has implementation experience

I’m not sure we require marking for all those; indeed, I think we should probably require that to get *in* to the Evergreen spec., you have the specs and implementations already.

Marking age on every feature is impractical. In case of doubt, pull a 180-day-old version and see if the feature was there then. It’s cooked if (a) it was and (b) there are no pending objections, errata (which DO require marking).

> 
>> However,
>> there's often a time gap between having a) and having b) and c). The
>> amount of time lag between agreement on a proposal and two demonstrably
>> interoperable implementation can vary greatly, from a few weeks for a
>> well-coordinated fix, to years.
>> 
>> If the agreed changes are not known to implementers, then implementers
>> working on that area of the codebase will not know about them, and may
>> end up compounding the amount of work necessary in the future and/or
>> implement the wrong thing. Additionally, anyone reviewing a spec needs
>> to know about impending changes. It's one thing to have a PR with
>> tentative changes while you discuss them for a couple weeks to get the
>> wording right. It's another to have pending changes that represent
>> consensus hanging around in a PR for months and years.
>> 
>> ~fantasai

David Singer

singer@mac.com

Received on Thursday, 21 March 2019 17:17:25 UTC