[tei-council] Editing the Guidelines

[Martin Holmes]

I agree that we should be relying on Jenkins primarily; in fact, it's 
the only thing we can really rely on, because local build environments 
can vary a lot, and what works locally may fail when you run it on 
Jenkins anyway. This is especially true now that we're building on 
Jenkins with the SVN version of the stylesheets; if you build locally 
with your Debian-packaged stylesheets, they'll be out of date compared 
with the SVN versions.

However, I think it's probably not a bad thing to provide instructions 
to help people do a basic validation of the Guidelines XML. When you 
start editing the Guidelines, it's slightly daunting to realize that 
you're editing fragmentary files that can't be validated as you work. 
The two-step xmllint -- noent... followed by validation against the 
Jenkins p5odds.rnc should work well to reassure people before they 
commit changes, especially the first few times they edit.

Cheers,
Martin

On 12-05-16 02:58 AM, James Cummings wrote:
> On 16/05/12 03:52, Rebecca Welzenbach wrote:
>> If that's right, instead of expanding this step, I suggest that the
>> sentence "Make sure your source is still valid against the p5odds.rnc
>> schema," either just be dropped altogether, or become part of the
>> bullet underneath, "If you have a locally installed P5 build
>> environment, make sure you can still build, and that the examples are
>> still valid," so that it's clear this is part of the process of
>> checking your work with a local build, but can be safely ignored if
>> you're just going to commit and wait for results from Jenkins.
>
> I do think that is right and that this should be made even more
> explicit. (i.e. say "You do not have to be able to build P5
> locally as Jenkins should test that P5 can still build and that
> the examples are still valid. Those with local P5 build
> environments can check locally that their changes are valid
> before committing, but this is not required."  (I like seeing the
> mistakes that others make, personally, it is informative.)
>
> What do others think? I realise that if too many people are
> committing errors then we can get Jenkins into quite a state and
> it can be quite a delay, but I think the default assumption
> should be that we are relying on it, not on individual
> contributors to build/test/validate everything.
>
> -James
>