See also: IRC log
<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
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: 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 :)
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]