Re: Removing EME persistent-usage-record "at risk" feature

On Thu, Oct 27, 2016 at 9:06 AM, Philippe Le Hégaret <plh@w3.org> wrote:

>
>
> On 10/27/2016 11:54 AM, Mark Watson wrote:
>
>> On Oct 27, 2016, at 5:14 AM, Philippe Le Hégaret <plh@w3.org> wrote:
>>>
>>> On 10/26/2016 9:10 PM, Mark Watson wrote:
>>>> My question, though, is whether EME V2 should take the form of a
>>>> completely new version of the specification that would (eventually)
>>>> replace the existing one​, or whether we should have a stand-alone
>>>> specification adding the "persistent-usage-record" session type. The
>>>> latter is hard to do without monkey-patching unless we introduce
>>>> explicit extension points.
>>>>
>>>
>>> Hi Mark,
>>>
>>> here is what I would recommend we do:
>>>
>>> We don't touch the gh-pages branch. Instead, we create a V1 branch for
>>> now and use that one to remove whatever we need to.
>>>
>>
>> Ok, so in this case the Editor's Draft at the normal
>> ED github link will still contain the feature and I suppose becomes
>> (de facto, but not officially) an ED of V2.
>>
>> This is ok for me.
>>
>
> correct.


I think we should keep the gh-pages branch synced to V1 until we figure out
a plan for VNext. The TR/ version, code, etc. reference this, and it is the
latest version of the REC-track spec. While it's not clear to me whether we
can make Type 3 changes (from your other email) in GitHub (but not in TR/),
if we were to, I would think they would be made in gh-pages. I'd
also caution against prematurely defining a “V2” before we have a clearer
idea of how VNext will be developed.

>
>
> If folks want to
>>> publish a separate Note for the removed feature, there will always be
>>> time to remove the feature from the gh-pages branch later on.
>>>
>>
>> My hope is that the removed feature is standardized at a later time,
>> since I do not expect it will be that long before there are compliant
>> implementations (perhaps early next year).
>
>
> Understood.


Specific to persistent-usage-record or any other removed feature, forks can
always reference earlier commits, including reverting the PR that removed
them. For now, I recommend maintaining a fork that contains a revert of the
removal. That will allow development of that/those feature(s) to continue
without worrying about process (i.e. Type 3 changes), and as a fork, it can
always be merged in at the appropriate time.

>
>
> Philippe
>
>