I mean the TCWs mainly. Documentation about Council procedures, not about
the Guidelines per se.
On Mon, Aug 8, 2016 at 11:37 AM, Lou Burnard
What seemed backwards was moving the data to satisfy the software rather than fixing the software, but I don't feel strongly about it. I'm puzzled by "we already maintain our documentation outside the TEI repo for the most part" though. What documentation is that then? The wiki? the website? We do have quite a lot of important documentation in the repo, notably for the exemplars. Should that move to the new proposed repo?
Looking again at https://github.com/TEIC/TEI/issues/1267 it's clear that something is not working as it should: the build triggered by changes to some parts of the repo is not far-reaching enough -- the exemplar schemas are apparently just being copied instead of being regenerated. I'm trying to check how long it is since they *were* actually regenerated, but not having access to the website makes this a touch difficult.
On 08/08/16 16:27, Hugh Cayless wrote:
Well, the event that triggers it is a new commit being pushed to GitHub. There's no way to tell what's in the commit without inspecting it. I don't know if there's a way around that. There is an FSTrigger plugin that monitors the file system and triggers builds based on changes to particular files/directories. I suppose you could have a separate process that does git operations and use that, but setting it up and replicating it might be a pain.
It doesn't seem backwards at all to me, because we already maintain our documentation outside the TEI repo for the most part. This would just mean not putting it in there in the first place...
On Mon, Aug 8, 2016 at 11:06 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:
On 08/08/16 15:05, Hugh Cayless wrote:
migrated, so I'm behind on posting the minutes with no way to catch up. I'm thinking I may just start a "documentation" repo and put both the minutes and the TCW docs there. I don't really like having documentation in the TEI repo, as updating the docs really shouldn't trigger a Jenkins build.
This seems backwards. I quite agree that updating the docs shouldn't
Kevin has asked that we freeze posting in the CMS until it has been trigger a Jenkins build but is it really the case that the only way to fix that is to move Documentation to an entirely different repo? Surely Mr Jenkins could be persuaded to be a bit more selective about what wakes him up?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived