Re: Making editors' drafts public

While we’re about it, is there anything we can do to reduce the problem of CVS conflicts on the generated HTML?

What typically happens to me as that I do a build, try to commit, and get a commit failure because someone else has done a build in the meantime and so my HTML files are not “up to date”. I then typically revert the HTML and do a new build - all very time-consuming. CVS doesn’t know that they are generated files and therefore there is no need for them to be up to date. Perhaps the build scripts should do an automatic CVS update on the html directory at the start? 

Normally I would say that automatically-generated files shouldn’t be held under a version control system. But then we need a different way of uploading them. Perhaps this is our opportunity.

One other point: it would be nice if the build scripts could automate getting the right date on documents. It’s very confusing when editors’ drafts carry a date that’s very different from the date of the last edit.

Michael Kay
Saxonica


> On 7 Oct 2015, at 03:10, Liam Quin <liam@w3.org> wrote:
> 
> Part of moving to being public Working Groups (XSLT and XQuery both) is that editors' drafts should be made public.
> 
> This isn't as simple as moving the old Member-only document-staging-area to somewhere public. We also need to use different CSS style sheets on the generated HTML - to say "editor's draft" so that people don't get confused and think they are looking at a Rec. People seem very easily confused about that.
> 
> I think that can be automated on a per-spec basis, so a possibility is
> 
> [1] minimal, and I think sufficient:
> * on a commit of Overview.html in any spec in qt-pecs, a process will copy the HTML into a public area and also change the CSS
>  as needed;
> 
> * the list of specs for which this is done would be maintained by hand.
> 
> More disruptive:
> [2] move to using public CVS for specs, or
> 
> [3] move to using github
> 
> I'm not in favour of [3] because it's needless disruption right now, and because it'd break the build system.
> 
> A consequence of [2] would be that the CVS logs might become public - or we could abandon CVS version history and check in clean versions of everything.
> 
> [1] is more work for the team (that's fine) and [2] is more work and more disruptive for the editors (not fine) so I propose that we do [1] and will pursue this unless I hear otherwise.
> 
> I'll post the list of specs before making any changes.
> 
> Are there any other changes needed to the documents to make them public? Maybe adding something to the status section to note that they are in progress and not in fact Candidate Recommendation documents (or whatever)?
> 
> Liam
> 
> 
> -- 
> Liam Quin, W3C
> XML Activity Lead;
> Digital publishing; HTML Accessibility
>

Received on Wednesday, 7 October 2015 08:02:29 UTC