the Great Tooling Revolution

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

the Great Tooling Revolution

Michael Dyck
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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: the Great Tooling Revolution

Domenic Denicola
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 https://github.com/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.


[Ecmarkup]: https://bterlson.github.io/ecmarkup/
[Ecmarkdown]: https://github.com/domenic/ecmarkdown
[converter]: https://github.com/jorendorff/es-spec-html/
[Object.observe]: https://arv.github.io/ecmascript-object-observe/

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: the Great Tooling Revolution

Michael Dyck
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
> https://github.com/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?

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: the Great Tooling Revolution

Domenic Denicola
From: es-discuss [mailto:[hidden email]] 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: the Great Tooling Revolution

Brendan Eich-2
In reply to this post by Michael Dyck
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.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: the Great Tooling Revolution

Allen Wirfs-Brock
In reply to this post by Domenic Denicola

On Apr 8, 2015, at 12:19 PM, Domenic Denicola <[hidden email]> 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 https://github.com/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  “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.

Allen


[Ecmarkup]: https://bterlson.github.io/ecmarkup/
[Ecmarkdown]: https://github.com/domenic/ecmarkdown
[converter]: https://github.com/jorendorff/es-spec-html/
[Object.observe]: https://arv.github.io/ecmascript-object-observe/

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: the Great Tooling Revolution

Domenic Denicola
From: Allen Wirfs-Brock [mailto:[hidden email]]

> 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!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss