[tei-council] Commits, builds, errors and Jenkins

[Martin Holmes]

> A full build environment is *not* required for those wanting to
> make textual changes to the Guidelines.  Martin is undertaking to
> do a full build because he wants to make sure he can understand
> and eventually duplicate the process.

That's true, but I was starting from Lou's recommendation last Wednesday 
morning that whenever you change the source, you should test it with a 
local build before committing. He also suggested adding a test case to 
the build, to really make sure the changes does what you think it should 
do, but I haven't figured out how to do that yet; for my nested bibl 
thing, I was relying on the fact that my two examples of nested bibls 
were validated successfully.

Cheers,
Martin

On 11-04-20 02:08 AM, James Cummings wrote:
> On 20/04/11 05:03, stuart yeates wrote:
>> On 20/04/11 10:23, Martin Holmes wrote:
>>> What this means in practice is that, if there are many of us making
>>> changes and commits, we will only see the results of our commits (in
>> While I admit that this is a hypothetical danger, I'm not convinced at
>> how real it is, whether it's real enough that we should be worrying about.
>
> I'd agree with Stuart. Historically there have only been a small
> number of people committing at any one point, and even in that
> case, watching the version numbers of commit messages mitigates
> this.  One can also do SVN locking, if you are worried that
> someone might be about to make changes on the files you are
> working on.  'svn lock' locks the file for any other commits
> until you commit or 'svn unlock'.  But I don't think we really
> need that either.
>
>> Requiring those wanting to make textual changes to the guidelines to
>> have a full build environment seems like it raises technical barriers to
>> non-technical tasks, reducing the pool of people to do the work.
>
> A full build environment is *not* required for those wanting to
> make textual changes to the Guidelines.  Martin is undertaking to
> do a full build because he wants to make sure he can understand
> and eventually duplicate the process.  I'm going to be doing a
> bunch of documentary (non-schema affecting) changes and certainly
> not going to do a full build in between each of these.  I will
> make the change in the Guidelines text, do an xmlwf to check I've
> not made any xml typos, possibly validate the file (but if I'm
> just changing a few words probably not), and svn commit. The
> point about having a continuous integration server like Jenkins
> is I should then be able to see that my changes are still valid
> and also see the result of them in an HTML rendering without
> needing to have a full build environment or similar on my
> computer.  The only required things for those doing non-schema
> related is a subversion client and a text editor.  (Ok, an XML
> editor makes more sense, and yes of course I happen to have a
> full build environment on several computers, but I only rarely
> actually run make before committing.) I'm not saying doing a full
> test on _any_ changes is a bad idea, quite the contrary, but it
> certainly shouldn't be required.
>
> -James
>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)