Skip to content

2018 road map

tripu edited this page Dec 7, 2017 · 3 revisions

2018 road map

Pain points

  1. Bikeshed, as opposed to Respec, isn't producing Echidna-ready snapshots (or is it?)
    • SotD must be removed from all pages in multi-page versions of specs (ie, the HTML5 spec)
    • SotD must be tweaked in other ways
    • Publication date must be changed
    • Order of style sheets must be changed
    • ⋮?
  2. Because of that, spec-generator doesn't support Bikeshed
  3. We currently maintain a double mechanism of authentication
    (token + URI / W3C credentials + TAR)
  4. We're not sure we can trust Travis with W3C credentials
    (even if they're encrypted) — can we?

Proposed alternative solutions

Integrate Bikeshed into spec-generator

  1. Bikeshed contributors work on solving the manual steps, so that the result is a valid snapshot
  2. Bikeshed could then expose a simple, comprehensive CLI interface that would produce Echidna-ready snapshots
  3. We work on spec-generator to support Bikeshed: spec-generator would invoke Bikeshed (as a local process) and obtain an Echidna-ready snapshot (we can't integrate it as an npm module because Bikeshed isn't Node.js, but Python)

Have a truly generator-agnostic publication process

We drop spec-generator, and Echidna relies entirely on:

  1. Travis CI hooked to spec repos
  2. Repos use Travis scripts to invoke whatever custom shell/Node/Pythong/etc scripts they need, at any stage of the build (eg, before and/or after Bikeshed/Respec do their thing)
  3. Groups can choose to either
    1. submit their snapshots directly from Travis (encrypting tokens or W3C credentials), or
    2. have Travis to push the snapshot back to some special branch in the repo, then invoke Echidna for that specific branch

Write a GitHub app, Systeam to maintain that service

  1. The app will be added to GH repos containing Bikeshed (or Respec) specs
  2. The app will run Bikeshed (or Respec) directly to produce a snapshot
  3. (Optionally,) the app will include a tinkering step at the end: WGs could then submit customs “scripts” that would perform certain necessary changes on those snapshots, to make them Echidna-ready
  4. The app would then push the result to a specific, separate, protected branch on the same GH repo
  5. After the push succeeds, the app could call Echidna for that new snapshot (no auth required, since it's the app talking to Echidna directly, and the snapshots branch is protected)