- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Fri, 6 Oct 2017 14:41:40 +0200
- To: "public-webrtc-editors@w3.org" <public-webrtc-editors@w3.org>
- Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Hi, As you may seen, our current process where the published editors draft doesn't reflect the latest stage of our master branch is creating confusion and is at odd with what other groups/repos are doing: https://github.com/w3c/webrtc-pc/issues/942 I have thus been working with the Chairs and with Cullen whose specific review needs have been a factor to the establishment of the current workflow to try and see if we can find a less confusing approach. I would thus like us to switch to the following approach after the next editors draft get published: * any PR will be automatically assigned for Cullen to review - the expectation is that this request for review is PURELY from an IPR perspective, not on the technical content of the PR (Cullen can and will naturally continue to provide feedback on the technical content e.g. via PR comments) * I'd make it so that PR can only be merged in master if Cullen has approved them (using Github PR approval's tool); Cullen has agreed to review all open PR at least the day before the scheduled editors call on Thursdays and has offered to provide 24h reviews on request (email or SMS) * I'd change our repo setup so that any PR merged gets reflected on github.io - in practice, that means getting rid of gh-pages as a separate branch, and use master as the branch used behind github.io; and make index.html a symlink to webrtc.html rather than a manually generated HTML version. This also means we would no longer maintained dated editors draft, nor need to run the release.sh script. The expectation is that each new editors draft would be published on TR as Working Draft (at least until we reach CR). I would want to apply this both to webrtc-pc and mediacapture-main - but first to the former. Feedback? questions? Thanks, Dom
Received on Friday, 6 October 2017 12:41:52 UTC