[presentation-api] Pull Request: Spec pubrules and Echidna compliant, WD generation semi-automated

tidoust has just submitted a new pull request for 
https://github.com/w3c/presentation-api:

== Spec pubrules and Echidna compliant, WD generation semi-automated 
==
This commit should contain all updates needed to be able to publish 
working
drafts to /TR/ space at W3C on a semi-automated basis.

The basic principle is to use a dedicated "TR" branch where we 
generate the
Working Draft to publish. Any push to that branch will trigger Travis 
CI
(provided it is enabled on the repository, obviously) that will, in 
turn,
send a publication request to Echidna at W3C with the right 
parameters.

Actually publishing the spec from a local checkout of the gh-pages 
branch
should look like:

git checkout TR
git merge gh-pages
make wd
git add releases/WD.html
git commit
git push w3c TR

Using a separate branch is not stricto senso necessary. I chose that 
option:
1. to have Working Drafts remain somewhat hidden on GitHub, the 
gh-pages
branch will only contain the Editor's Draft and that sounds a good 
idea
2. because it is easy to trigger Travis CI on a specific branch but 
not when
a when a specific file is updated.

In terms of changes, I updated the raw spec to be publication rules 
and
Echidna compliant, adding the editors IDs, updating the way version 
links
are managed, and the Status of This Document section so that it might 
be used
without modification in a published Working Draft.

I also created a "wd" Makefile rule to generate the releases/WD.html 
file that
can be provided to Echidna for immediate publication. The generated 
WD.html
file is not part of this commit but has been checked with success 
against
Specberus, the new pubrules checker.

Note that the Makefile now uses "curl", "grep" and "sed" to extract 
the URL of
the latest published WD, used to compute the Previous Version link in 
the
generated Working Draft. This is all a bit hacky but should work fine 
in most
cases, except when publishing the spec more than once in a given day. 
The
"previous version" link can be manually checked and overwritten by 
some editor
before committing the working draft in any case.

Also note that Specberus does not like trailing spaces in "href" in 
the
"This version" and other similar links. We have them because of a 
combinaison
of us using Tidy to enforce 80-character-long lines and Anolis that 
uses a
specific syntax based on comments for these links ("<!--begin-link-->"
 and
"<!--end-link-->"). I worked around that using Anolis "[VERSION]" and
"[LATEST]" substitution strings that do not get truncated in the 
source spec
and thus do not generate spaces in the end. The issue has been 
reported to
Specberus folks:
 https://github.com/w3c/specberus/issues/207

I also added what I believe would be the right ECHIDNA manifest file 
and the
right .travis.yml configuration file to automate the publication. This
 will
perhaps need to be adjusted when we try to publish the first working 
draft.

See https://github.com/w3c/presentation-api/pull/113

Received on Wednesday, 10 June 2015 19:51:23 UTC