disable auto publish since the spec is now CR

[deniak]

Echidna only works for WD and Notes. Since the spec is now a CR, the requests to Echidna will always fail.

---

This change is 

[andreastt]

It’s not obvious to me that this is a great idea. Please correct me if I’m wrong, but we’re still doing the finishing touches to the spec that is up for CR, and it would make sense to continue updating the CR draft with the latest bug patches.

[deniak]

Unfortunately, at this point, Echidna can only handle WD and Notes, so if you want to update the current CR, you'll have to send a publication request and we will publish it manually.

[andreastt]

When you say “send a publication request and we will publish it manually”, what do you actually mean? Where do we send this request and what does “manual” entail?

[deniak]

The steps to publish a CR are described here. It involves the team contact, webmaster, communication team, director, etc.
Basically, the publication will be done by a human instead of a system such as Echidna.

[andreastt]

The two points that seem to be relevant here are:

• The group must provide public documentation of all substantive changes to the technical report since the previous publication or a statement that there is no substantive changes. Include, for example, a link to a change log where important changes are highlighted.
• The group should provide public documentation of changes that are not substantive.

All the changes that have been made since the specification transitioned to CR are non-substantive, in the meaning that we have made no changes to the public APIs or behavioural changes to the function of the API. The changes have in other words all been non-substantive.

There is public documentation of these changes in the form of the commit log, which in most cases include descriptive commit messages, and/or links to issue reports and pull request conversations.

We already have the contact information for @sideshowbarker, but can you point to which other emails we need to involve to make a change? I’m sure this process could be automated using cron with emails.

[deniak]

Since CRs will have to be published manually, we can't possibly update the CR after each commit. The WG will have to decide when is a good time to update the CR and follow the steps described here to request a new publication.

[andreastt]

That seems like a fundamentally broken patch process. It would not seem unreasonable to want software, including specifications, to be fixed as soon as possible.

As far as I read the process document you linked to, there is no formal rule preventing us from making non-substantive changes as long as they are well-documented, so I don’t see why those have to be manually reviewed. If the bottleneck indeed is review capacity at W3C, that is a different problem. But as I said, technically, these changes should not be controversial.

Would it not be possible to modify Echnida to have a special flag which we can set, possibly picked up from the commit message on our side before calling the publish script, indicating whether a substantive change is involved?

[deniak]

That's actually the goal. We want Echidna to be able to publish FPWD and CR as well so people don't have to wait for their documents to be published.