Re: Publish a new Candidate Recommendation for Presentation API?

I noticed that the CR is dated July 14 but the last commit on the 'TR'
branch was on May 6.  So there may be even more changes between the
editor's draft and the CR.

I counted about 10 "substantive" changes since 7/14 (fixes to WebIDL,
steps, or other descriptions of behavior), versus editorial fixes or fixes
to example code.

On Tue, Nov 22, 2016 at 5:16 AM, Francois Daoust <fd@w3.org> wrote:

> Hi Mark, all,
>
> Le 22/11/2016 à 02:20, mark a. foltz a écrit :
>
>> Francois, Anssi,
>>
>> I was wondering if we should set a milestone of publishing a new
>> Candidate Recommendation, given the amount of work that has happened
>> since the last one was published.  Please let me know what your thoughts
>> are from a process point of view.
>>
>
> The Process requires the publication of a revised Candidate Recommendation
> as soon as substantive changes were made [1]. We resolved ambiguities in
> algorithms. Such changes fall into the "substantive changes" bucket and we
> did a number of them, so I believe the group needs to publish a revised
> Candidate Recommendation (CR).
>

Agreed.

Looking at milestones in the WG charter [2], we said publication as a final
> Recommendation would happen by end of June 2017 (Q2 2017). A spec must
> remain at the Proposed Recommendation (PR) stage during at least 4 weeks, a
> bit more in practice. This means publication as PR would need to happen by
> end of May 2017. A spec must remain at the CR stage during at least 4 weeks
> as well. This means we need to publish a revised CR end of April 2017 at
> the very latest.
>


> Things take longer in practice each time for various reasons (e.g. time
> needed to schedule a call with the Director, last-minute comment from a
> member during PR review, etc.).
>
> With that in mind, I would say the group should aim for the publication of
> a final CR beginning of March 2017.


> We do not have to wait until then though! We could typically publish a
> revised CR as soon as outstanding issues have been resolved. We would still
> have time to publish a third CR if we uncover new issues afterwards.
>

Okay, we've made some progress addressing outstanding issues in GitHub, but
new ones seem to be cropping up.  Maybe we should checkpoint when we've
been able to address the remaining issues.

Two additional questions that I think the group should consider before
> publishing a revised CR:
>
> 1. The current CR does not single out any "at risk" feature (features that
> could be removed from the spec without publishing a new CR if they end up
> not being supported). Can implementers confirm that they plan to support
> all features defined in the spec?
>

>From Chrome's point of view we intend to support all features in the spec.

2. Current CR exit criteria include "at least one implementation of the
> 1-UA mode and one implementation of the 2-UA mode" for the receiving side.
> TPAC discussions suggested this criterion might need to be relaxed. Are we
> confident we'll have at least one 2-UA receiver implementation in
> particular?
>

I believe we have a path forward for at least one 2-UA implementation in
Chrome.  We may not be able to support multiple simultaneous controllers
connecting to a 2-UA presentation at in a Q1 2017 time frame, but we will
try our best.

Thanks,
> Francois.
>
>
> [1] https://www.w3.org/2015/Process-20150901/#revised-cr
> [2] http://www.w3.org/2014/secondscreen/charter-2016.html#deliverables
>