- Tei-council - lists.tei-c.org

Re: [Tei-council] TCW 20 Revision on Branch Practice?
by James Cummings 03 Oct '18

03 Oct '18

I'd say that not all tickets are Guidelines related (e.g. we have a label for TEI:Website and another for TEI:Build Process), so perfectly reasonable to have a ticket as a place for conversation about this that we might return to in the future. That is assuming that this is something that might have several iterations, tests, decision about which is the best way, etc. If it is a straightforward "Let's test this, oh look, it works now let's document that." then maybe a ticket is not needed. My two pence, James -- Dr James Cummings, James.Cummings(a)newcastle.ac.uk School of English Literature, Language, and Linguistics, Newcastle University ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Elisa Beshero-Bondar <ebb8(a)pitt.edu> Sent: 03 October 2018 12:10:28 To: TEI Council Subject: Re: [Tei-council] TCW 20 Revision on Branch Practice? PS: Should I open that as a ticket? Since it's not specifically Guidelines-related, I'm not sure...figured I'd sound us out here first. Thanks, Elisa On Wed, Oct 3, 2018 at 7:08 AM Elisa Beshero-Bondar <ebbondar(a)gmail.com<mailto:ebbondar@gmail.com>> wrote: Dear Council, I was just re-reading TCW 20 to remind myself what we advise each other on working in feature branches, and how to update them. You may remember some excitement during our Tokyo face-to-face as I first nearly bungled a branch merge and then we fixed it. This was, I think, a bit too much excitement, and lots of us do work in branches. When it comes time to update them and/or merge them back into dev, we don't always know exactly what to do, and just relying on looking stuff up is, as we saw, a little brittle and error prone. We are pretty confident we can fix anything that goes wrong, but perhaps we can minimize the excitement with a little more guidance to our future selves. So, I'm writing this to propose some revision to this portion of TCW 20: "If you are working on a particularly complex change involving multiple files, it may be better to create a branch in which to work on your changes, and then to merge the branch when you are confident that the work is successfully completed. See any guide to git for instructions on how to approach that. Bear in mind that our Jenkins servers only build the dev branch, so you cannot depend on them to test-build your working branch." I'd like to propose rewriting that with some more detailed steps on our TEI Technical Council preferred process for reconciling branches with dev, to help prevent future excitement. :-) I've been reading about the "best" ways to keep branches updated, and the differences, for example, between rebase and merge for keeping a branch tip updated. Rebasing is pretty dangerous in that it "rewrites history" by resequencing commits, so I am not sure we ever want to use it for updating a branch from dev, before merging it back. Do we want to always advise, then, to update a branch by merging it with dev? I'm not 100% certain of that either. What I'd like to do is (very careful) test a few approaches and work with you all to try to plot out an excitement-proof set of safe guidelines for Council members on Best Practices for Working in Branches as part of TCW 20. What say you all? Elisa -- Elisa Beshero-Bondar, PhD Associate Professor of English University of Pittsburgh at Greensburg Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu<mailto:ebb8@pitt.edu> -- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu<mailto:ebb8@pitt.edu> Development site: http://newtfire.org<http://newtfire.org/>

4 3

TCW 20 Revision on Branch Practice?
by Elisa Beshero-Bondar 03 Oct '18

03 Oct '18

Dear Council, I was just re-reading TCW 20 to remind myself what we advise each other on working in feature branches, and how to update them. You may remember some excitement during our Tokyo face-to-face as I first nearly bungled a branch merge and then we fixed it. This was, I think, a bit too much excitement, and lots of us do work in branches. When it comes time to update them and/or merge them back into dev, we don't always know exactly what to do, and just relying on looking stuff up is, as we saw, a little brittle and error prone. We are pretty confident we can fix anything that goes wrong, but perhaps we can minimize the excitement with a little more guidance to our future selves. So, I'm writing this to propose some revision to this portion of TCW 20: "If you are working on a particularly complex change involving multiple files, it may be better to create a branch in which to work on your changes, and then to merge the branch when you are confident that the work is successfully completed. See any guide to git for instructions on how to approach that. Bear in mind that our Jenkins servers only build the dev branch, so you cannot depend on them to test-build your working branch." I'd like to propose rewriting that with some more detailed steps on our TEI Technical Council preferred process for reconciling branches with dev, to help prevent future excitement. :-) I've been reading about the "best" ways to keep branches updated, and the differences, for example, between rebase and merge for keeping a branch tip updated. Rebasing is pretty dangerous in that it "rewrites history" by resequencing commits, so I am not sure we ever want to use it for updating a branch from dev, before merging it back. Do we want to always advise, then, to update a branch by merging it with dev? I'm not 100% certain of that either. What I'd like to do is (very careful) test a few approaches and work with you all to try to plot out an excitement-proof set of safe guidelines for Council members on Best Practices for Working in Branches as part of TCW 20. What say you all? Elisa -- Elisa Beshero-Bondar, PhD Associate Professor of English University of Pittsburgh at Greensburg Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8(a)pitt.edu

2 1

two dates are not better than one
by s.bauman＠northeastern.edu 02 Oct '18

02 Oct '18

When I went to actually nuke data.*.xml, I ran into a problem. There were two that were still referenced in the Guidelines: data.temporal.iso.xml and data.duration.iso.xml from ND.[1] I initially "fixed" this by just changing "data." to "teidata." on those two instances in ND. This broke the build horrifically -- the definitions of various attrs (like att.temporal.when.iso) now had *two* lists of possible values. Took some digging around but I found that the "correct" datatypes (teidata.duration.iso.xml, and teidata.temporal.iso.xml) were (incorrectly, I think) still being referenced from ST. I commented out those references in ST, and the build was back to normal (and matches the prose). So that all seems good. BUT, there is still a problem. This means that there are several validation errors that have now crept in: memberOf points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso ident points to non-existent att.duration.iso specDesc points to non-existent att.duration.iso I am not quite sure what to do about this. While technically validation problems, they don't (I don't think) actually cause any difficulties when building outputs from the source. So rather than check these changes into dev, I have (with Hugh's help) checked them into a new branch, sydb-endDeprecation_2018-10-01. But we should decide what to do about this soon (measured in hours to days), as the deprecation period is now over. One possibility (that I am leaning towards right now): These errors are generated by the special-purpose validation routine P5/Utilities/validator.xsl, referred to in the Makefile with "Check validity with special-purpose XSL code, looking for bad links etc". We could simply update that code so it "knows" about these particular cases, and does not flag them as errors. But before we even think of that, either a) someone else who builds locally should checkout the sydb-endDeprecation_2018-10-01 branch and check that the build is working. (I only tested validate, html-web, and exemplars, I think.), or b) we'll have to ask MH or PS to set up a Jenkins job for this branch. (Seems like overkill to me.) Note-for-Vanessa ---------------- [1] The vast majority of the source files to Guidelines chapters are each stored in an XML file that starts with a 2-letter code. Thus I am using "ND" as shorthand for .../P5/Source/Guidelines/en/ND-NamesDates.xml where "..." is wherever on your system you keep the TEIC/TEI git repo. The chapter files are: * AB-About.xml * AI-AnalyticMechanisms.xml * CC-LanguageCorpora.xml * CE-CertaintyResponsibility.xml * CH-LanguagesCharacterSets.xml * CO-CoreElements.xml * DI-PrintDictionaries.xml * DR-PerformanceTexts.xml * DS-DefaultTextStructure.xml * FS-FeatureStructures.xml * FT-TablesFormulaeGraphics.xml * GD-GraphsNetworksTrees.xml * HD-Header.xml * MS-ManuscriptDescription.xml * ND-NamesDates.xml * NH-Non-hierarchical.xml * PH-PrimarySources.xml * SA-LinkingSegmentationAlignment.xml * SG-GentleIntroduction.xml * ST-Infrastructure.xml * TC-CriticalApparatus.xml * TD-DocumentationElements.xml * TS-TranscriptionsofSpeech.xml * USE.xml * VE-Verse.xml * WD-NonStandardCharacters.xml

5 5

Stylesheets v7.46.0 released
by Raffaele Viglianti 02 Oct '18

02 Oct '18

Dear council, Syd and I, with the help of Martin Holmes and Peter Stadler, have just completed a new release of the stylesheets v7.46.0. In the process, we've also made a couple of updates to tcw22 and the utility script tei-install.sh. I don't know if stylesheets releases need to be announced on TEI-L, especially since we don't assemble a document listing changes besides a generated changelog. The freeze on the dev branch is now over, code away. Raff

5 7

validity of newly <msDesc>-only elements
by s.bauman＠northeastern.edu 01 Oct '18

01 Oct '18

Per previous deprecation (see #1479), I went to change the deprecation of the use of <secFol>, <signatures>, or <catchwords> outside of <msDesc> to an error. HOWEVER, when we do that we get validation errors on <egXML> that has only one of those three elements without any context. SO I changed the actual Schematron to <sch:assert test="ancestor::tei:msDesc or parent::teix:egXML"> The <sch:name/> element should not be used outside of msDesc. </sch:assert> and changed the 2 <egXML>s that had <catchwords> as a descendant, but not child, so that they each contain an <msDesc> wrapper. I'm not entirely sure why that works -- I thought example validation was done by changing the namespace of each example to the TEI namespace and then validating against a (modified) TEI schema. But perhaps I'm wrong about that, or perhaps it's smart enough to change the teix: prefix to be the TEI namespace, too. Anyway, it seems to be working now, but because of other problems is only checked into the new sydb-endDeprecation_2018-10-01 branch. (Thanks to Hugh for helping me straighten out my git headaches.)

1 0

Customization section of TEI
by Mylonas, Elli 01 Oct '18

01 Oct '18

There is a section of TEI under the "Guidelines" menu item called Customization. Issue 1813 https://github.com/TEIC/TEI/issues/1813 points out some problems that are eminently fixable. However, what Syd and I were unable to determine is where the source lives (other than on disk) and how to edit the file(s). Help appreciated. Signing off as the September Issue Assigner. best, --elli

1 0

changing branch tracking?
by Syd Bauman 01 Oct '18

01 Oct '18

Attn: Hugh I made a lot of changed to my local dev branch today for tomorrow's removal of macroSpec/@type allowing <catchwords>, <secFol>, and <signatures> outside of <msDesc> data.*.xml There were problems that will probably break the build (more about those later -- probably as soon as this is dealt with :-), so I decided I should have used a different branch. So I issued: $ git reset --keep HEAD~3 $ git checkout -t -b sydb-deprecationEnd_2018-10-01 $ git cherry-pick ..HEAD@{2} It looks like it *mostly* worked: $ git status -uno | Your branch is ahead of 'dev' by 3 commits. | (use "git push" to publish your local commits) | nothing to commit (use -u to show untracked files) But there are 2 problems: 1) A typo. That "HEAD~3" was supposed to be a "HEAD~5" 2) The 'dev' in that status output makes me worry that if I do a `git push`, these changes would get pushed to dev, not the new sydb-deprecationEnd_2018-10-01 branch. I was smart enough to make a backup of my entire repository before doing this, so I can go back and fix my 3/5 mistake easily. But I thought the point of the -t switch was to set up tracking so that my local sydb-deprecationEnd_2018-10-01 tracks a similarly named branch on the remote (GitHub). Apparently not. What do I do to make that work?

2 1

reminder doodle poll
by Scholger, Martina (martina.scholger＠uni-graz.at) 01 Oct '18

01 Oct '18

Dear Council, this is a reminder for the doodle poll for scheduling our TEI Council calls: https://doodle.com/poll/kk9hsr6z9csxhkub Please add possible dates if you haven't done it yet. Best, Martina

1 0

Just testing to see if I can post
by Martin Holmes 30 Sep '18

30 Sep '18

Hi all, Ignore me, I'm just finding out whether I have permission to post to the Council list. Cheers, Martin

2 1

Referring to the TEI Stylesheets on the web
by Peter Stadler 28 Sep '18

28 Sep '18

Hi Council, hi Martin, the subject is a little misleading, so let me explain the issue (sorry, lengthy again): Say, you want to build the TEI Guidelines but don’t have the TEI Stylesheets installed/downloaded on your machine. In the Makefile (under TEI/P5) you’ll find the following lines ``` XSL=/usr/share/xml/tei/stylesheet # If you have not installed the Debian packages, uncomment one # of the next two lines: #XSL=../Stylesheets/release/tei-xsl/p5 #XSL=http://www.tei-c.org/stylesheet/release/xml/tei ``` which suggests that you can point to an online resource for the Stylesheets (see the last line of the code snippet). Yet, that does not work and probably never(!) worked, because in the ant built file (TEI/P5/antbuilder.xml) the stylesheets are called like ``` <xslt processor="trax" force="yes" style="${XSL}/odds/odd2json.xsl" in="p5subset.xml" out="p5subset.js“> ``` i.e. the respective stylesheet is pointed to from the @style attribute. But this @style attribute can not (and probably never could) refer to an URI, see https://ant.apache.org/manual/Tasks/style.html <https://ant.apache.org/manual/Tasks/style.html> – only filenames. URIs can be consumed by the ANT XSLT task, but then we’d need to replace the @style attribute with a nested style element. When using a nested style element (with an appropriate url element), we’re getting in trouble with our current practice which is to only use relative paths (almost) everywhere but without providing a proper scheme. This seems like a whole can of worms and I already tried several things but nothing really worked without rewriting too much code. Any comments and/or ideas are welcome Peter

2 3

Update Council members
by Scholger, Martina (martina.scholger＠uni-graz.at) 28 Sep '18

28 Sep '18

Hi all, I updated the terms of the Council members on the website: http://www.tei-c.org/activities/council/ Please let me know if your affiliation has changed or if you want your name linked to a website. Best wishes, Martina

1 0

Stylesheets release starter question
by Syd Bauman 28 Sep '18

28 Sep '18

Who am I supposed to ask for the TEI-C GPG key passphrase? Whoever it is, could you send it (off list) to me or Raff? Thanks! (Unless you already have it, Raff.)

1 0

when to meet? Doodle poll invite
by Syd Bauman 28 Sep '18

28 Sep '18

Per Martina, here is our Doodle poll for scheduling future TEI Council monthly teleconference calls. This poll is only about which day of week and what time, not about 1st, 2nd, 3rd, 4th, last, or whatever week of month. All times are UTC, and thus shift an hour for DST. 12:00Z, earliest time ------- -------- ---- 07:00 EST, 08:00 EDT 12:00 GMT, 13:00 BST 13:00 CET, 14:00 CEST 21:00Z, latest time ------- ------ ---- 16:00 EST, 17:00 EDT 21:00 GMT, 22:00 BST 22:00 CET, 23:00 CEST I can't speak for others, but here in USA [1] we will "fall back" from DST to standard time on Sun 04 Nov; except that Florida is trying to exempt itself from ever using standard time -- they want to use DST all year. So Sarah, you should keep abreast of that. A good list of time changes is available at https://www.timeanddate.com/time/dst/2018.html Notes ----- [1] Except for AZ and HI, which do not observe DST at all. But we don't have any Council members in either of those states. :-)

4 4

Stylesheets release freeze -- better late than never
by Syd Bauman 27 Sep '18

27 Sep '18

We have just created the release branch for Stylesheets (which we should have done last week). So feel free to push to 'dev' branch, but nothing should go to 'release-7.46.0' branch unless approved by me or Raff. Could Martin & Peter create appropriate jobs in Jenkins, please? Thanks.

2 1

Meeting in 20 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 27 Sep '18

27 Sep '18

Hi all, we start in 20 minutes. https://docs.google.com/document/d/1uGtDk4AoOvHXTV6EzdSeyo-D5ItsAz7PBnKtHIg… --Martina

2 1

Re: [Tei-council] meeting?
by Scholger, Martina (martina.scholger＠uni-graz.at) 27 Sep '18

27 Sep '18

Hi Syd, I actually sent out the agenda and hangouts link on Tuesday. Hope everyone got it. Just in case: Our conference call is today, starting at 12:00Z-13:30Z (08:00-9:30 EDT, 13:00-14:30 BST, 14:00-15:30 CEST) This is the agenda: https://docs.google.com/document/d/1uGtDk4AoOvHXTV6EzdSeyo-D5ItsAz7PBnKtHIg… Hangouts: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil Best wishes, Martina -----Ursprüngliche Nachricht----- Von: Tei-council <tei-council-bounces(a)lists.tei-c.org> Im Auftrag von Syd Bauman Gesendet: Donnerstag, 27. September 2018 00:08 An: TEI Council <tei-council(a)lists.tei-c.org> Betreff: [Tei-council] meeting? RELAX NG namespace in Schematron Welcome aboard, Vanessa! Martina -- are we in fact meeting tomorrow, and if so a) at what time?[1,2] b) can you post the URLs for both the Hangout and the agenda & minutes sooner rather than later? All -- I'm working on the "normal" ODD->Schematron pathway (odds/extract-isosch.xsl, i.e. the process that creates a standalone Schematron schema, not the one that embeds Schematron into RELAX NG) in response to Stylesheets #250. The code in that program always generates an <sch:ns prefix="rng"> element to declare the RELAX NG namespace in the output Schematron. I presume when it was put in it was needed because some Schematron rule or other used "rng:" in its @context or @test attribute. But the string "rng:" does not occur in *any* attribute in all of P5 now. (And the only elements in the RELAX NG namespace are inside <egXML> or in data.XXX, soon to be deprecated.) So I am planning to nuke the automatic generation of <sch:ns prefix="rng"> in this routine. (It will still get generated if there are definitions that specify it on their @ns, or an <sch:ns> element that defines it, or it is a namespace in force for one of the definitions.) If anyone knows of a reason it should stay, please speak up soon (or revert my change). Notes ----- [1] 12:00Z = 08:00 EDT, 13:00 BST, 14:00 CEST 13:00Z = 09:00 EDT, 14:00 BST, 15:00 CEST Sorry, I don't know your time zone, Vanessa. [2] IIRC we agreed to 13:00Z, but then again, I thought we agreed not to have a teleconference the last Thu of Oct, too. _______________________________________________ Tei-council mailing list Tei-council(a)lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

1 0

meeting? RELAX NG namespace in Schematron
by Syd Bauman 27 Sep '18

27 Sep '18

Welcome aboard, Vanessa! Martina -- are we in fact meeting tomorrow, and if so a) at what time?[1,2] b) can you post the URLs for both the Hangout and the agenda & minutes sooner rather than later? All -- I'm working on the "normal" ODD->Schematron pathway (odds/extract-isosch.xsl, i.e. the process that creates a standalone Schematron schema, not the one that embeds Schematron into RELAX NG) in response to Stylesheets #250. The code in that program always generates an <sch:ns prefix="rng"> element to declare the RELAX NG namespace in the output Schematron. I presume when it was put in it was needed because some Schematron rule or other used "rng:" in its @context or @test attribute. But the string "rng:" does not occur in *any* attribute in all of P5 now. (And the only elements in the RELAX NG namespace are inside <egXML> or in data.XXX, soon to be deprecated.) So I am planning to nuke the automatic generation of <sch:ns prefix="rng"> in this routine. (It will still get generated if there are definitions that specify it on their @ns, or an <sch:ns> element that defines it, or it is a namespace in force for one of the definitions.) If anyone knows of a reason it should stay, please speak up soon (or revert my change). Notes ----- [1] 12:00Z = 08:00 EDT, 13:00 BST, 14:00 CEST 13:00Z = 09:00 EDT, 14:00 BST, 15:00 CEST Sorry, I don't know your time zone, Vanessa. [2] IIRC we agreed to 13:00Z, but then again, I thought we agreed not to have a teleconference the last Thu of Oct, too.

2 1

Next Meeting: September 27
by Scholger, Martina (martina.scholger＠uni-graz.at) 26 Sep '18

26 Sep '18

Hi all, our next conference call is on Thursday September 27 (08:00 EDT, 13:00 BST, 14:00 CEST). Here is the agenda - please add your topics: https://docs.google.com/document/d/1uGtDk4AoOvHXTV6EzdSeyo-D5ItsAz7PBnKtHIg… I'm happy that Vanessa will join us for the meeting. For the call we usually use this Google Hangouts connection: https://hangouts.google.com/hangouts/_/brown.edu/teicouncil. Vanessa, you should already have access to the minutes. Please let me know if not. Best wishes, Martina

3 5

Congrats and welcome
by Scholger, Martina (martina.scholger＠uni-graz.at) 25 Sep '18

25 Sep '18

Dear all, congratulations to everyone who got (re-)elected to the TEI Technical Council for the next two years! I'm delighted that Hugh, Raff, Sarah and Syd will be joining us for another run of office and I want to welcome our new member Vanessa Bigot-Juloux to the Council. Looking forward to a productive year! Best wishes, Martina Martina Scholger Zentrum für Informationsmodellierung - Austrian Centre for Digital Humanities Elisabethstraße 59/III 8010 Graz Austria martina.scholger(a)uni-graz.at<mailto:martina.scholger@uni-graz.at> https://informationsmodellierung.uni-graz.at<https://informationsmodellierung.uni-graz.at/> | https://gams.uni.graz.at<https://gams.uni.graz.at/> Chair of the TEI Technical Council | http://tei-c.org Institut für Dokumentologie und Editorik e.V. | https://i-d-e.de<https://i-d-e.de/>

1 0

tei website links
by Lou 18 Sep '18

18 Sep '18

Of the six links on the page http://www.tei-c.org/support/Learn/ all but two are currently broken. Is no link checking in place or is this a temporary issue?

2 1

Update on Docker and Travis
by Peter Stadler 14 Sep '18

14 Sep '18

Dear all, as I reported during our Council meeting on Saturday(?) I wanted to clean up and reorganize our Docker images a little bit. Here’s a little update on my work so far: a) every DockerHub repo is now turned into an „automated build“. This results in a better GitHub integration since every commit to a GitHub repo will trigger a fresh built of the respective Docker image at DockerHub. Sadly, there is no way of converting an existing repo so I had to nuke the Jenkins and the teidev-docker repos and recreate them. Hence, all stars and pull statistics got lost :( b) because some repos do not get frequent commits, I added a cron job at my server to regularly trigger a rebuild of those images to keep them updated with their upstream images. Now that I’m writing this, I think that would make a nice Jenkins job. Will try and report back! c) I was originally thinking that I’d like to alter the teidev-docker image to inherit from our Jenkins image (so we need to maintain only one Dockerfile with the software dependencies) – but when I was working on this it occurred to me, that we actually could be doing everything with the Jenkins image alone (by overwriting the entrypoint and cmd directives) and don’t need a dedicated image for building the Guidelines etc. locally. If you want to give it a try, install Docker, navigate to your Stylesheets directory and enter the command: `docker run --rm -w /var/odd -it -v `pwd`:/var/odd --entrypoint "make" teic/jenkins:dev test ` This will run the tests on your machine, with your local files, with the software environment from the Jenkins Docker image. That’s cool, ain’t it? d) I was taking first steps with Travis for RomaJS and it’s great fun, because (again) it integrates with GitHub so seamlessly. What we gain is automated testing for every branch and every pull request, nice badges, and even Slack notifications ;) So, I added this Travis integration to the Stylesheets repo as well, using the Docker image and the above Docker command for testing. Another really cool thing IMHO, because (thanks to Docker) the commands run are using the very same software environment as our Jenkins does. If you want to check, have a look at the .travis.yml file in the Stylesheets repo which is driving the integration tests. [1] BTW, everybody who is a member of the GitHub TEIC organisation should be able to login and see/alter all the stuff at https://travis-ci.org/TEIC <https://travis-ci.org/TEIC>. Of course, these new opportunities bring up a few new ideas. Here’s the proposal bit: 1) since we do not need a dedicated Docker image for building locally, I propose to delete the repo at DockerHub. At GitHub, I propose to archive the repo. Instead, I will add a section to the Jenkins Readme on how to build locally with the Docker image. Any other reference on how to build the Guidelines should be updated as well and have at least a pointer to the Jenkins Readme and the Jenkins Dockerfile. That would serve as our main „infrastructure as code“ documentation on how to set up the build environment. 2) I propose to add Travis integration to the TEI repo as well and set it up to (only) run the Tests (i.e. `make clean validate test`). Since the Guidelines depend on the Stylesheets to build, Travis would need to get them from Jenkins lastSuccesfullBuild (as Jenkins is currently doing) 3) Once we have the Travis integration, I propose to turn our dev branches into "protected“ branches. That means, on the pull request pages on GitHub (and only there) the test results will be added. An example for how this looks like can be seen at [2]. The advantage is for the issuer of the pull request to directly see whether it’s working or not. If the tests are failing the pull request is marked as „blocked“, but as an administrator (and probably all Council members have this role?) you are still able to merge. 4) A mid term goal could be to use Travis for running the tests and have Jenkins only build the artefacts. We could even replace Jenkins completely but then we’d need another place to push our build artefacts to. Sorry for the lengthy mail. Best Peter [1] https://github.com/TEIC/Stylesheets/blob/dev/.travis.yml [2] https://github.com/eXist-db/exist/pull/2153

2 2

Session chair
by Scholger, Martina (martina.scholger＠uni-graz.at) 13 Sep '18

13 Sep '18

Hi all, I apologize, but I can't make it to the conference today since I'm sick. I'm scheduled to chair the first session at 9. It is the session where Elisa, Raff and Magda give their presentations. Could anyone please chair the session for me? Best, Martina Von meinem Huawei-Mobiltelefon gesendet

3 3

Dinner tonight
by Scholger, Martina (martina.scholger＠uni-graz.at) 09 Sep '18

09 Sep '18

Hi all, We will meet Susanna Alles after the workshops (around 6:30 pm) at Hitotsubashi Hall and go for dinner. Raff recommended a noodle place close to the APA hotel. Hope to see you! Martina Von meinem Huawei-Mobiltelefon gesendet

3 2

Dinner someone?
by Peter Stadler 06 Sep '18

06 Sep '18

Dear all at Tokyo, I hope, most of you who are attending the Council meeting have already arrived safely? Are there any dinner plans for tonight? Martina and I would love to join if you want our company :) If there are no plans already, what about meeting at 19:00 at the Fresa Inn (https://goo.gl/maps/YXyP5g88j492) and then look for some place to eat? Looking forward to meeting ya all Peter

3 2

Council meeting - Infos
by Scholger, Martina (martina.scholger＠uni-graz.at) 04 Sep '18

04 Sep '18

Dear Council, Kiyonori sent us some information for the Council meeting and dinner(s). He would like to invite us and other TEI/JADH/ADHO members to a dinner on Saturday evening. Please check out the details in his email below. The room number for the Council meeting is B1 at Hitotsubashi Hall. Save travels and see you soon in Tokyo! Best wishes, Martina -----Ursprüngliche Nachricht----- Von: Kiyonori NAGASAKI <nagasaki(a)dhii.jp> Gesendet: Montag, 3. September 2018 15:00 An: Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Cc: Kiyonori NAGASAKI <nagasaki(a)dhii.jp> Dear Martina, I'm sorry for my delay on this matter. As written in the following URL, https://tei2018.dhii.asia/boardandcouncil The Council meeting will be held in a room on 2nd floor at the conference venue on Friday and Saturday. Please come to there. During the two days, I will stay at the room to support the meeting. There are many restaurants around the venue. You can find them on various map tools. I strongly recommend to avoid general lunch time because the restaurants will be usually filled with many office workers. I put some lunch places and a convenience store on the map for TEI2018 https://tei2018.dhii.asia/accomodations and will add some more restaurants. We would like to invite the members of the Council with other TEI and JADH/ADHO members to a dinner on Saturday from 18:00. I will take you to the restaurant. Please notify that light meals will be provided on lunch break time on Monday after the Council open meeting due to the short lunch time. After that, please join in the official banquet on Monday and the Board-Council dinner and Karaoke on Thursday. Moreover, we're planning to hold casual dinner arranged in groups on Tuesday, please wait for a while. Please let me know if you have other things you want to know. Best wishes, Kiyonori

1 0