W3C

- DRAFT -

Automatic publication of specs

28 Oct 2015

See also: IRC log

Attendees

Present
Regrets
Chair
tripu
Scribe
vivien, plh

Contents


<tripu> scribe: vivien

<scribe> scribe: plh

<scribe> scribe: vivien

tripu: goal of this system is to make publication easier
... goal of this system is to make publication easier

antonio: appart to the API we have email notification (simply says if it was published or not, if not the issues)
... more and more groups working on github are joining
... making it possible for you to publish as often as you wish without human intervention
... so far only handling WDs
... echidna is the core of the systeam, we you only want to publish you should only care about echidna and specberus (the new pubrules checker)
... if you contain more than one file, you can use echidna-manifester that from your file find all resources to generate a manifest file
... echidna has a REST API, you can now also use echpub wich is a CLI
... recent changes: Process 2015, emails when things are failing with more detailed about errors, now handling joint publication, also better handling of same-day publications
... Now basic support basic for exceptions
... eg use of css that is not yet known by the CSS Validator
... contact us if you need for some exceptions

<plh> https://github.com/w3c/specberus/pull/261

antonio: coming in the next months

<scribe> ... new type of documents

UNKNOWN_SPEAKER: user friendly error messages
... by next year specberus as the only official pubrules checker
... smarter retrieval of information less relying on metadata
... integration with linkchecker
... richer API
... nice to have: dashboard and stats

antonio: the new types of specs
... other types of WDs like non normative ones, then Notes and FPWDs
... thx to the one of you that helped us with early feedback that greatly helped us shape the tool

questions

richard: how soon is soon for FPWD ?

antonio: I am hoping it will be done in a matter of a few weeks

richard: in i18n we want to have the TR drafts and the editor drafts be the same
... interested by non normative WDs

TabAtkins: I'm trying to understand the REST API

<plh> curl 'https://labs.w3.org/echidna/api/request' --data 'url=http://w3c.github.io/ime-api/W3CTRMANIFEST&decision=https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0627.html&token=4972101275c6850.96930607'

TabAtkins: requiring a URL rather than the data seems strange, as you need to generate the TR version and can't directly use the editor draft

<plh> https://labs.w3.org/spec-generator/?type=respec&url=http%3A%2F%2Fw3c.github.io%2Fhr-time%2Findex.html%3FspecStatus%3DWD%3BshortName%3Dhr-time-2

plh: if you happen the manifest of this spec, it tells you it is a respec document, when echidna sees that it is going to require a service to generate the draft
... and that creates the html it will use for the publication
... it is similar for bikeshed

TabAtkins: the api does not allow you to specify the version of the document you want to publish
... how do you know I want to publish a WD or NOTE ?

plh: you are right we don't handle that currently we only deal with WDs, we will have to add a parameter to set a differnt type

SimonSapin: could we use zip files that contain the generated files

antonio: the reason we did not accepted that was security concern, like you can upload big files
... I like to see echidna as being generator agnostic

<plh> index.html?specStatus=WD;shortName=navigation-timing-2 respec

fantasai: so what would be an example of publishing a document that does not use any specific generator

plh: the html document itself
... what I pasted above comes from a manifest

antonio: I can show an example

s/speaker1/TabAtkins/g

s/speaker2/SimonSapin/g

antonio: 1st parameter a url, then decision to publish which is another url (link to minutes or mailing list email), then the token
... it returns a job id
... and with this job id I can get its status to see if the document was published
... any step of echidna will return a status
... it does not matter if you are using travis so it makes it easy to integrate with other tools

fantasai: @@@
... what about images ?

TabAtkins: bikeshed can generate a manifest

fantasai: we would want the manifest to be on a server and the files being on another server

plh: today links are relative and needs to be on the same server

TabAtkins: can it be on a higher level ?

plh: I think so

fantasai: [explaining on the whiteboard what the file manifest would be for CSS documents]

plh: Echidna knows about bikeshed so will do thing correctly

plh & antonio: we need to check regarding relative uris

<plh> https://github.com/w3c/echidna/blob/master/lib/document-downloader.js

TabAtkins: can I sent that manifest directly to your API isnetad of having to commit it to my repository

SimonSapin: I think we want echidna to obtain a set of files, currently it needs a manifest. You don't you directly send the list of files like in a server

antonio: there are issues in unzipping files on a server

fantasai: how is it less of a problem than if I give you a link to a 600MB file

TabAtkins: the less we have to rely on another server the better

antonio: we had not received that feedback so far

fantasai: ahve you talked to the XML folks ?
... allowing a tar file seem easier, and that would answer our use case

SimonSapin: I said zip file but it could be any format

fantasai: you are doing extra work for people using respec, but it should be also easy for people using other tools

TabAtkins: people would simply need to do bikeshed echidna arguments then done

SimonSapin: @@@2

TabAtkins: most people run bikeshed locally so they already have the generated stuff locally, they should not have to put it remotely

antonio: it is good you are here guys because most people we talked with were respec users

SimonSapin: I prefer we don't invent a new format as it will require several lines of codes, so use standard formats

ted: I was opposed to zip

TabAtkins: we are fine with any format

SimonSapin: what about uncompressed tar files

plh and antonio: ok we will consider it

antonio: any otehr things missing ?
... BTW on the wiki you have examples

TabAtkins: question about the spec token, I assume it should be kept private

plh: correct

antonio: the token is associated with the source URI

vivien: so with tar files ?

plh: would still be a file URI

SimonSapin: the important part of what I said earlier is inventing a new format for the manifest

plh: if you give us a tar file we would no need the manifest
... if someone gets your token it will only be able to republish your document
... the team contact has a way to get the token

TabAtkins: so not a security concern if it is in a public repo

plh: we would rather not to avoid possible DoS attacks

TabAtkins: the naive ideal I expect is to put the pub token in the document meta data, so that bikeshed reads the metadata and launch the publication

<plh> https://github.com/w3c/hr-time/blob/gh-pages/.travis.yml

<fantasai> TabAtkins, so what we'd do is store the tokens in a mapping file that's not in the repo, but is stored on another server

SimonSapin: travis ci allows to have private files

<fantasai> that can be any server, but in our case it would be /Style/Group/pub-tokens.txt or something

<fantasai> bikeshed then needs to know only the URL to that token list, and it can then find the token it needs based on the shortname

antonio: you can also handle branches

<fantasai> if we use /Style/Group/, it's behind an http password check, so it's not public

<fantasai> and every CSSWG member has an account for accessing that; it's their W3C account

plh: the pb we have today is it is opaque you ahve to monitor the mailing list

antonio: today you have to poll the API to get the status let's say every 5 minutes

<denis> fwiw, a request should be processed in less than 1min

antonio: I suggest you look at the other groups that are using travis to see how they handled that
... groups that are using one repository for multiple specs have some issues
... travis could guess it based on the files that were modified

SimonSapin: not easy to guess that from git

zcorpan: is it possible to edit multiple specs in a single commit ?

TabAtkins: should work

plh: we lower the bar for entry by using echidna, meaning eg echidna does not runs linkchecker for WDs

fantasai: you could run the linkchecker once a day on drafts and complain to people

antonio: you could mark those links are broken

plh: we could had exceptions for this

antonio: I would rather mark which links are going to be broken in case of cross publications
... break time

TabAtkins: I am going to spend time on bikeshed in the upcoming months for that

fantasai: it would make us happy if we use echidna

[session adjourned]

<tripu> +1 to TabAtkins :)

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/28 06:44:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/echdna-manifester/echidna-manifester/
Succeeded: s/publich/publish/
Succeeded: s/speaker1/TabAtkins/
Succeeded: s/speaker1/TabAtkins/
Succeeded: s/speaker2/SimonSapin/
FAILED: s/speaker1/TabAtkins/g
FAILED: s/speaker2/SimonSapin/g
Succeeded: s/ for you//
Succeeded: s/handle/handled/
Succeeded: s/you could/travis could/
Succeeded: s/speaker4/zcorpan/g
Succeeded: s/qntonio/antonio/
Found Scribe: vivien
Inferring ScribeNick: vivien
Found Scribe: plh
Found Scribe: vivien
Inferring ScribeNick: vivien
Scribes: vivien, plh

WARNING: No "Present: ... " found!
Possibly Present: ShaneM SimonSapin TabAtkins antonio astearns denis dom fantasai https joined katsu plh pub r12a richard shepazu ted tripu vivien zcorpan
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 28 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/28-pub-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]