Re: Proposal: use only github for new MSE spec bugs

The spec update PR is pending review @
https://github.com/w3c/media-source/pull/13.

On Tue, Oct 13, 2015 at 3:11 PM Matt Wolenetz <wolenetz@google.com> wrote:

> Thanks for the pointer. It looks like the origin of that utility script
> (webcomponents) no longer uses it, either. I'll remove it for MSE for now.
> Matt
>
> On Tue, Oct 13, 2015 at 3:03 PM David Dorwin <ddorwin@google.com> wrote:
>
>> I believe there is a <script> tag and some <meta> tags near the top of
>> the ReSpec source. I commented them out in EME since it pointed to
>> Bugzilla. I'm sure the script could be adapted; it's possible someone has
>> done that since I last looked.
>>
>> David
>>
>> On Tue, Oct 13, 2015 at 2:55 PM, Matt Wolenetz <wolenetz@google.com>
>> wrote:
>>
>>> What's the correct way of removing the "See a problem? Select text and
>>> [file a bug]" box at the top right of the MSE spec? I noticed this refers
>>> to the w3c bug tracker; also, the EME spec does not include this box.
>>>
>>> On Tue, Oct 13, 2015 at 2:14 PM Jerry Smith (IEP) <jdsmith@microsoft.com>
>>> wrote:
>>>
>>>> Perfect.
>>>>
>>>>
>>>>
>>>> *From:* Paul Cotton
>>>> *Sent:* Tuesday, October 13, 2015 11:59 AM
>>>> *To:* Matt Wolenetz <wolenetz@google.com>; David LaPalomento <
>>>> dlapalomento@brightcove.com>
>>>> *Cc:* Jerry Smith (IEP) <jdsmith@microsoft.com>; <
>>>> public-html-media@w3.org> <public-html-media@w3.org>
>>>> *Subject:* RE: Proposal: use only github for new MSE spec bugs
>>>>
>>>>
>>>>
>>>> >I assume I should resolve the original w3c bug as "MOVED" with an
>>>> appropriate link to the github bug.
>>>>
>>>> Works for me!
>>>>
>>>> Sent from my Windows Phone
>>>> ------------------------------
>>>>
>>>> *From: *Matt Wolenetz
>>>> *Sent: *13/10/2015 2:10 PM
>>>> *To: *David LaPalomento; Paul Cotton
>>>> *Cc: *Jerry Smith (IEP); <public-html-media@w3.org>
>>>> *Subject: *Re: Proposal: use only github for new MSE spec bugs
>>>>
>>>> As discussed in this morning's media task force MSE teleconf, I'll file
>>>> new github issues for each of the currently active w3c bugzilla MSE spec
>>>> bugs and link to them from the w3c bugs, and update the bug tracker links
>>>> in the editor's draft.
>>>>
>>>>
>>>>
>>>> *Paul/Jerry*: Once I've created the corresponding github bug, I assume
>>>> I should resolve the original w3c bug as "MOVED" with an appropriate link
>>>> to the github bug. Is this correct? This would allow us to more easily
>>>> discover newly filed w3c MSE bugs that might still happen after this
>>>> migration.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>> On Fri, Oct 9, 2015 at 8:23 AM David LaPalomento <
>>>> dlapalomento@brightcove.com> wrote:
>>>>
>>>> As a developer very interested in MSE but less involved in the w3c
>>>> process, a big +1 to this proposal. Having both trackers is a bit confusing
>>>> and I suspect having more activity occurring in github will encourage the
>>>> huge community active there to participate more.
>>>>
>>>>
>>>>
>>>> On Thu, Oct 8, 2015 at 8:17 PM, Paul Cotton <Paul.Cotton@microsoft.com>
>>>> wrote:
>>>>
>>>> > Would it make sense to make placeholder github issues for existing,
>>>> open, w3c MSE bugs, and restrict all MSE spec bug activity to github issues?
>>>>
>>>>
>>>>
>>>> I have no problem with us doing as long as we add a comment to each of
>>>> the former 19 Bugzilla bugs pointing forward to the appropriate GitHub
>>>> issue.   I suggest you go ahead and do this ASAP.
>>>>
>>>>
>>>>
>>>> >2. Is it possible to update the w3c bug tracker to indicate that new
>>>> MSE bugs or activity on existing w3c MSE spec bugs should occur on github's
>>>> issue tracker?
>>>>
>>>>
>>>>
>>>> I am not sure how to do this.
>>>>
>>>>
>>>>
>>>> > Which versions of the MSE spec would need updating to reference
>>>> using github as the primary issue tracker for spec bugs (just the current
>>>> editor's draft, or some retro-active editing of earlier published snapshots
>>>> of the spec too?)
>>>>
>>>>
>>>>
>>>> W3C does not normally change even the Status section of published
>>>> documents.  And for older documents we would NOT want to get rid of the
>>>> pointer to the Bugzilla component since historically it is the right
>>>> pointer.
>>>>
>>>>
>>>>
>>>> I would recommend that the best way to make sure that people are
>>>> looking at a TR page specification with the correct Status information is
>>>> to get going on turning on automatic publication of Editor’s draft for MSE
>>>> as we have for EME.  I believe Jerry has an action to look into that.
>>>>
>>>>
>>>>
>>>> /paulc
>>>>
>>>>
>>>>
>>>> Paul Cotton, Microsoft Canada
>>>>
>>>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>>>>
>>>> Tel: (425) 705-9596 Fax: (425) 936-7329
>>>>
>>>>
>>>>
>>>> *From:* Matt Wolenetz [mailto:wolenetz@google.com]
>>>> *Sent:* Thursday, October 08, 2015 7:18 PM
>>>> *To:* <public-html-media@w3.org>
>>>> *Subject:* Proposal: use only github for new MSE spec bugs
>>>>
>>>>
>>>>
>>>> At the moment, we are using both w3c and github to track open MSE spec
>>>> bugs.
>>>>
>>>> At the recent FOMS 2015 & Demuxed 2015 conferences, we heard praise
>>>> from other attendees of the move by EME to primarily using github's issue
>>>> tracker.
>>>>
>>>> In light of EME's move to gh for new issue tracking, external appeals
>>>> of similar for MSE, and to consolidate tracking of all new MSE spec bugs, I
>>>> propose that we move to using solely github for tracking newly opened MSE
>>>> spec bugs.
>>>>
>>>>
>>>>
>>>> Before moving forward, I would like to understand better:
>>>>
>>>> 1. Would it make sense to make placeholder github issues for existing,
>>>> open, w3c MSE bugs, and restrict all MSE spec bug activity to github issues?
>>>>
>>>> 2. Is it possible to update the w3c bug tracker to indicate that new
>>>> MSE bugs or activity on existing w3c MSE spec bugs should occur on github's
>>>> issue tracker?
>>>>
>>>> 3. Which versions of the MSE spec would need updating to reference
>>>> using github as the primary issue tracker for spec bugs (just the current
>>>> editor's draft, or some retro-active editing of earlier published snapshots
>>>> of the spec too?)
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>>
>>