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

On Thu, Oct 27, 2016 at 9:12 AM, David Dorwin <ddorwin@google.com> wrote:

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

​I don't think PRs reference an Editor's Draft - at least the PRs I could
find do not.

Anyway, whilst we should certainly have two branches, one for the V1 REC
track version and one for the V2 ED version, there is no reason the ReSpec
output for both cannot be in the gh-pages branch so that both have github.io
addresses.

Also, there is a significant difference between "at risk" features removed
from V1 because they did not quite meet the implementation bar but are
expected to soon and entirely new VNext features. We've previously
discussed - with general consensus - that we should move to a more agile
publication cadence, so I expect we will be publishing V2 fairly soon,
wherever we publish it.

...Mark
​


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