Release is on Tuesday. That was the plan Raven or no. --elli can't speak to Stylesheets. My impression from TCW22 is that you push to release and that we make sure to merge back to dev. On Fri, Jan 25, 2019 at 4:48 PM Syd Bauman wrote:

JC> Re: html:* passthrough. JC> Sure, but I know SPQR used it for things locally in Oxford as JC> well. But you could probably remove without side-effect. I doubt JC> many other people are using them. (Though, how would we know?)

I have no plans to change it. Just to chuckle at it.

JC> re: highlighting github lines in a link. JC> Cool isn't it. ;-) ...

Way

JC> Re: nuking ref JC> I'm assuming you mean only the ones wrapped around gi? As there JC> are some (pointing to things like classes etc) that we do need, JC> obviously.

I am going to process <ident type="class"> to <a>, too, so would nuke those. Those around <att> and <title> would have to stay put.

JC> Let me know if I can help,

Yes -- what should the *content* of the new <a class="X" href="http://VAULT/VERSION/ref-THING.html"> (where X is either "gi" or "class") be? I am guessing <duck> for an element, and just the name of the class (e.g., att.quack or model.webbed.feet) for a class. Let me know if that's not right. Also, I have not even thought about what, if anything, should be done to the CSS.

EM> ... [the "Raven" release.]

I like it. (But of course I would, I suggested it. :-) Does mean we have to really try to get it out on Mon 29 Jan.

EM> Please do not commit any further changes, unless they are to the EM> release notes or unless you communicate first with the release EM> technicians or the chair. Release technicians are Hugh Cayless EM> and myself.

I probably won't be done with this README change for an hour or two, anyway. But the questions are, when I'm done a) do we want to try to release on Monday with the new code or not? b) if yes, to which branch should I commit it? (And of course, the corresponding changes to the README .xml files themselves should go to the equivalent branch, but one is in Stylesheets/, the other in TEI/.) c) if no, to which branch should I commit it? (dev, right?) _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

Am 25.01.2019 um 23:20 schrieb Syd Bauman :

...

My impression from TCW22 is that you push to release and that we make sure to merge back to dev.

OK, will do unless someone speaks up and says otherwise. It does not look like there is a new release branch for the Stylesheets. Just commit to dev there? (I.e., what Stylesheets branch do our CI servers use to build TEI branch release-3.5.0?)

Usually there was a release branch for the Stylesheets as well. Right now, I updated the Jenkins release jobs for the Guidelines to 3.5.0, using the *dev* branch of the Stylesheets. If you added a release branch for the Stylesheets, I’ll switch to that. See https://jenkins.tei-c.org/view/Release/ Best Peter

Current state is a bit problemetaic. Because there is no release branch for the Stylesheets, and no one has answered my queries here of 01-25 16:47 and 01-25 17:20 (my time zone, I think), I don't know where I should push these changes. (I also don't know what is the *right* way to push them, per my query of 01-25 19:03, but I can get around that w/o much difficulty.) If I don't hear otherwise by tomorrow, I'll just make myself new branches, push the changes there, and let the release techs sort it out. (May even send a pull request :-) Sounds a bit mean, but it is certain not to make anything worse. I don't *think* this will cause any problems with the release. I have tested the change only in the positive -- that the changes I expect to see in the readmeX.html files are as expected, not in the negative: I have not looked for errors elsewhere. Thus it makes me a bit nervous to make a change this close. On the other hand, that's (in part) why we have a version control system, and Hugh is quite adept at it.

Thank you Syd for taking care of the release notes processing. I just wanted to check what the current state is. As I see it, this shouldn't cause any problems with the release? Any concerns from the release techs?

Apologies, I'm just catching up after being away for the weekend. If we're doing a Stylesheets release, I really think we ought to have a release branch. Is it ok if I make one?

No worries. You're the release tech, so I say "go for it"!

Done. Sorry, busy morning. https://github.com/TEIC/Stylesheets/tree/release-7.47.0 On Mon, Jan 28, 2019 at 10:33 AM Scholger, Martina ( martina.scholger@uni-graz.at) wrote:

Yes, please create a release branch for the Stylesheets. Syd, changes will now be pushed to the release branch - if that was your question. The release technicians will push them back to dev.

Martina

-----Ursprüngliche Nachricht----- Von: Tei-council Im Auftrag von Syd Bauman Gesendet: Montag, 28. Jänner 2019 14:24 An: TEI Council Betreff: Re: [Tei-council] release branch

...

Apologies, I'm just catching up after being away for the weekend. If we're doing a Stylesheets release, I really think we ought to have a release branch. Is it ok if I make one?

No worries. You're the release tech, so I say "go for it"! _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

I duely added the new Stylesheets release branch to the Jenkins release jobs and updated the subsequent TEI jobs to pick up this branch. It’s building right now: https://jenkins.tei-c.org/view/Release/ Best Peter

Am 28.01.2019 um 21:31 schrieb Syd Bauman :

OK. I should be checking in the README changes in roughly 2-3 hours, if that's OK.

...

Done. Sorry, busy morning.

---

Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

One more wrench to throw in here. Once in awhile there is a <gi> that is from the TEI scheme, but probably should not point directly to the vanilla P5 version in the vault. The (only) specific example I've seen is: The content model of http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-affiliation.html"

<gi>affiliation</gi></ref> in the jTEI schema ...

Should that <ref> point to the jTEI documentation, not vanilla TEI? Should that <gi> have a scheme="jTEI"? My instinct for right now is not to worry about it, as the result of the new system won't make it any worse than it is now. But we should do something to allow a <gi> to purposefully point somewhere other than auto-generated. For now, having a @scheme other than 'TEI' or 'tei' would do the trick. But maybe James' idea of ignoring a <gi> that is already inside a <ref> should be implemented, too. Am I good to go checking this in? And while I'm at it, gitsters, how do I do that? I did the work in a local copy that was checked out to dev. I have not committed it, let alone pushed, yet. I could, of course, * clone a new copy of repo * check out release branch in that new repo * copy my modified pgm to new repo copy release branch * commit it * push it * warn release techs about it * revert my dev directory with `git checkout -- profiles/readme/html/to.xsl` But there's probably a better GIT way to do this, eh?