- From: Marcos Caceres <marcosc@w3.org>
- Date: Wed, 19 May 2021 14:31:02 +1000
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: W3C Devices and Sensors WG <public-device-apis@w3.org>, Reilly Grant <reillyg@google.com>, Fuqiao Xue <xfq@w3.org>
> On 18 May 2021, at 8:04 pm, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote: > > Thanks for the reminder, I'm supportive of enabling Echidna-based publication workflow. I sent a separate mail about this to the group to clarify the scope. Sounds great. >> (We could even then get rid of the “ED" versions entirely, as the TR version would become canonical). > > > My personal view is it might be useful to be able to decide whether a push triggers a TR update or not. E.g. an editorial update might not always warrant a new TR snapshot. Or ED could sometimes be used for staging purposes and a TR publication only makes sense when multiple separate but related changes have landed. The problem with using ED for staging is that it is confusing to anyone that doesn't know that the ED is not authoritative/canonical. In other words, we should avoid having anything in an ED that doesn't have group consensus. To overcome the "ED for staging" issue, [pr-preview] elegantly covers the cases you describe above: working group members and the public can view/discuss/share/link-to the changes proposed via a pull request before they are merged into the spec and end up on TR. Further, pr-preview specifically addresses the "is this authoritative?" problem by clearly labelling specs with "this is a preview" warning box and adding the "diff" markers. [pr-preview] https://github.com/tobie/pr-preview
Received on Wednesday, 19 May 2021 04:31:18 UTC