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 wrote:

On 08/08/16 15:05, Hugh Cayless wrote:

...

Kevin has asked that we freeze posting in the CMS until it has been 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 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

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 wrote:

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

Missed it because it didn't have a label. I'm not altogether happy with standardizing stuff before best practices have had a chance to emerge, but maybe I should just say that on the ticket... On Mon, Aug 8, 2016 at 12:37 PM, Lou Burnard wrote:

BTW, you didn't assign https://github.com/TEIC/TEI/issues/1483 to anyone. Homer nodded, or you couldn't face it?

-- 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

How about using the wiki feature on the TEI repo to host the Council minutes until the CMS is ready? This would seem to be a logical place to host them, since it is connected to the documentation we provide in the tickets via Issues--and would be findable by the same people on and off Council who follow our work closely. Elisa Typeset by hand on my iPad

On Aug 8, 2016, at 10:27 AM, 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 wrote:

...

...

On 08/08/16 15:05, Hugh Cayless wrote:

Kevin has asked that we freeze posting in the CMS until it has been 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 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