W3C home > Mailing lists > Public > public-html-media@w3.org > October 2015

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

From: David LaPalomento <dlapalomento@brightcove.com>
Date: Fri, 9 Oct 2015 11:22:59 -0400
Message-ID: <CACh87oc67oC_M=7k40aW7i-EfM_R9kGteHX9F7Ff3KQtsv-cGQ@mail.gmail.com>
To: Paul Cotton <Paul.Cotton@microsoft.com>
Cc: Matt Wolenetz <wolenetz@google.com>, "Jerry Smith (IEP)" <jdsmith@microsoft.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
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
>
Received on Friday, 9 October 2015 15:23:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:06 UTC