the Great Tooling Revolution
This was discussed briefly at the previous meeting, perhaps un-minuted.
The basic plan is to develop the spec on GitHub, using Ecmarkup and Ecmarkdown. It will take pull requests, have a master branch that you can view (and implementers should view, to see any bug fixes made since the Ecma version), etc.
Brian did a prototype conversion a while back, based on an older draft and an older dialect of Ecmarkup (no Ecmarkdown); you can find that at bterlson/ecmascript. I believe the current status it that we're waiting for the "final" GA-submitted version before doing the real conversion, since Allen is making editorial tweaks and bug-fixes up until the deadine. Once that's done we'll use some mutated version of Jason's converter and start iterating and tweaking from there.
Unlike the current process, the post-ES2015 spec process requires two shipping implementations before a feature is integrated into the spec. While we're waiting for that, we anticipate proposal documents to prepare for integration by being written as Ecmarkup/Ecmarkdown spec deltas, with their own issue trackers. For an example of this, see Object.observe.
There's been less discussion about what to do with the issues list: GitHub issues vs. bugs.ecmascript.org. At the very least I would hope that we welcome community issues on GitHub, even if bugs.ecmascript.org stays active.
On 15-04-08 12:19 PM, Domenic Denicola wrote:
This was discussed briefly at the previous meeting, perhaps un-minuted.
The meeting notes for Jan 29th have a section where ecmarkup/down is introduced and discussed somewhat, but there's no decision regarding its use.
The basic plan is to develop the spec on GitHub, using [Ecmarkup] and [Ecmarkdown]. It will take pull requests, have a master branch that you can view (and implementers should view, to see any bug fixes made since the Ecma version), etc.
Cool. That should improve some processes.
Brian did a prototype conversion a while back, based on an older draft and an older dialect of Ecmarkup (no Ecmarkdown); you can find that at bterlson/ecmascript. I believe the current status it that we're waiting for the "final" GA-submitted version before doing the real conversion, since Allen is making editorial tweaks and bug-fixes up until the deadine. Once that's done we'll use some mutated version of Jason's [converter] and start iterating and tweaking from there.
I'll probably volunteer to check the result, since I have a converter that's independent of Jason's. (It starts with the PDF rather than the docx.)
Unlike the current process, the post-ES2015 spec process requires two shipping implementations before a feature is integrated into the spec. While we're waiting for that, we anticipate proposal documents to prepare for integration by being written as Ecmarkup/Ecmarkdown spec deltas,
So not as git branches of the spec?
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Michael Dyck
So not as git branches of the spec?
I mean, I guess they could if they want, but that seems like a lot of work for the spec writer to be constantly rebasing. Better to only do the branch when it's time for a pull request, I'd imagine.
Michael Dyck wrote:
Unlike the current process, the post-ES2015 spec process requires two shipping implementations before a feature is integrated into the spec. While we're waiting for that, we anticipate proposal documents to prepare for integration by being written as Ecmarkup/Ecmarkdown spec deltas,
So not as git branches of the spec?
That might be better for significant cross-cutting changes, indeed.
On Apr 8, 2015, at 12:19 PM, Domenic Denicola <d at domenic.me> wrote:
This was discussed briefly at the previous meeting, perhaps un-minuted.
The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and [Ecmarkdown][]. It will take pull requests, have a master branch that you can view (and implementers should view, to see any bug fixes made since the Ecma version), etc.
I think generating feature spec’s on github, using these technologies is a fine idea.
Brian did a prototype conversion a while back, based on an older draft and an older dialect of Ecmarkup (no Ecmarkdown); you can find that at bterlson/ecmascript. I believe the current status it that we're waiting for the "final" GA-submitted version before doing the real conversion, since Allen is making editorial tweaks and bug-fixes up until the deadine. Once that's done we'll use some mutated version of Jason's [converter][] and start iterating and tweaking from there.
However, I’m skeptical that they will be the technologies used to actually publish ES2016. I suspect, that for 2016 we will end up manually integrate the new material into the Word document. Here’s why. We are immediately, upon GA approval, starting the ISO fastback approval process. Based upon past experience this will take about a year and produce a significant number of edits to the ES2015. spec. We need to keep those changes in sync with ES2016 work such that the final ISO spec. will probably be the ES2016 spec and it will need to be a Word document.
I support experiments working towards converting the entire spec. to alternative development approaches including proving that we can generate a paper publication quality version of the spec, and working with the ECMA and ISO/ JTC/1 on the publication pipeline. However, that is a lot of infrastructure work and I don’t think we should let it to get in the way of shipping our first yearly update.
Unlike the current process, the post-ES2015 spec process requires two shipping implementations before a feature is integrated into the spec. While we're waiting for that, we anticipate proposal documents to prepare for integration by being written as Ecmarkup/Ecmarkdown spec deltas, with their own issue trackers. For an example of this, see [Object.observe][].
There's been less discussion about what to do with the issues list: GitHub issues vs. bugs.ecmascript.org. At the very least I would hope that we welcome community issues on GitHub, even if bugs.ecmascript.org stays active.
There is already a bugs.ecmascript.org, bugs.ecmascript.org “product” for ES7 and it is open to community issues. We should certainly try moving towards GitHub issues for individual post ES7 feature proposals and it that works out well perhaps we can migrate the the ES7 bugs.ecmascript.org, bugs.ecmascript.org issues to github issues.
From: Allen Wirfs-Brock [mailto:allen at wirfs-brock.com]
However, that is a lot of infrastructure work and I don’t think we should let it to get in the way of shipping our first yearly update.
Thanks for pointing this out. I agree that we may be over-optimistic in thinking the new tooling will be completely production-ready in a year, and if it indeed falls short of that mark we should not let that be a blocker. I'm hopeful we can in fact accomplish it all in a year, but, Hofstadter's Law etc.
There is already a bugs.ecmascript.org “product” for ES7 and it is open to community issues. We should certainly try moving towards GitHub issues for individual post ES7 feature proposals and it that works out well perhaps we can migrate the the ES7 bugs.ecmascript.org issues to github issues.
Sounds like a plan!
In the March 24 meeting notes (e.g., rwaldron/tc39-notes/blob/master/es6/2015-03/mar-24.md ), there's the line: DD: once the great tooling revolution arrives, there will be a live GitHub version of the spec that implementers consult. but I don't see any discussion of this in the meeting notes or in es-discuss. Could someone describe the plan?
In the March 24 meeting notes (e.g., https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-03/mar-24.md ), there's the line: DD: once the great tooling revolution arrives, there will be a live GitHub version of the spec that implementers consult. but I don't see any discussion of this in the meeting notes or in es-discuss. Could someone describe the plan? -Michael