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

Scheduling
by Hugh Cayless 30 Dec '15

30 Dec '15

Hello All, I have three scheduling items for your consideration: January telecon: http://doodle.com/poll/h9c4wu85pqqvbcbe If we can, I’d like to schedule a regular monthly day / time for our meetings, say the third or fourth week of every month. To that end, please give me an idea of what days/times are *in general* possible or impossible for you this upcoming semester and beyond: http://doodle.com/poll/d3nyte4wuiiqt9r4 Spring F2F: http://doodle.com/poll/cd9n3d47e5ezfkit I’ve put together a set of options between mid-April and mid-May. How do people feel about working weekends? I’d prefer weekdays as a general rule, but I can compromise if need be. The current poll includes some Saturday dates, but not Sundays. We can change that of course if you need different dates. We can move earlier or later if need be. Scheduling these is usually a pain, and usually requires a couple of iterations. I hope you’ve all been enjoying whatever holidays you celebrate (or just some well-earned time off work) and I wish you a happy new year! Hugh

5 8

Roma documentation
by Martin Holmes 29 Dec '15

29 Dec '15

I've created a TCW here: <http://www.tei-c.org/Activities/Council/Working/tcw29.xml> explaining how Roma is deployed on tei-c, and how to deploy a new version. If you believe this is the wrong place for this information, feel free to move it to wherever it belongs. Cheers, Martin

1 0

Where should we document Roma configuration?
by Martin Holmes 28 Dec '15

28 Dec '15

HI all, Today the Roma install got updated to 4.18, which includes the bugfix I added for quotation marks in titles. That's a minor thing, but in the process, over the last couple of months, Ian Rifkin and I have been working out a setup which enables us to deploy and test new versions on tei-c without needing his intervention, and enables us to get him to switch from an old to a new version when we're ready just by changing a pointer. This all needs documenting, but the question is where should it go? It has slightly gnarly stuff like Apache rewrite rules and tei-c.org filesystem paths, so I'm not sure whether it belongs on the wiki, or in a TCW, or somewhere slightly more private. I think probably a TCW, but I thought I should check first. What do you think? Cheers, Martin

2 3

Oxgarage is out of date
by Martin Holmes 21 Dec '15

21 Dec '15

Hi all, If you convert an ODD file to a RelaxNG schema using OxGarage right now, you'll see this at the top of your file:  OxGarage hasn't been updated to use 2.9.1. I don't know what's actually involved here; perhaps OxGarage uses the P5 and Stylesheets versions from the debs, and the server hasn't been updated since 2.9.1 was released. Does anyone know how this works? Cheers, Martin

6 13

TEI Templates missing from Oxygen?
by Martin Holmes 20 Dec '15

20 Dec '15

Hi all, I just updated my Oxygen to the latest release, and I can't see any TEI P5 templates other than the JTEI template. This is an install which doesn't have the bleeding-edge version of the plugin installed. In the Framework folder I see all the relevant files, but I don't see anything other than JTEI when I go to File / New / Framework Templates. Can anyone else who's got the latest Oxygen check what you see? Thanks, Martin

3 3

GitHub Labels re-organized
by Raffaele Viglianti 18 Dec '15

18 Dec '15

Deal all, As promised at the F2F, Elli and I have re-organized the GitHub labels before the year end. You can see the current labels here: https://github.com/TEIC/TEI/labels Thank you for your feedback earlier this week - we took it into account, but made some executive decisions. None of this is set in stone, however, as changing and adjusting the labels is easy. Let's give this setup a test drive and see how it works for us. I've also gone through the issues that are currently open and made sure they all have at least one label for *Status:**, *TEI:** or *Tool*:*, and *Type:**. Best, Raff

1 0

Git question
by James Cummings 18 Dec '15

18 Dec '15

Hiya, Is there a way to copy the changes I've made on one branch to another? Or move one branch (off another branch) to be tracking a different branch instead? (e.g. I made the 'processing-model' branch off of Lou's original lb42-pureodd branch and I want to move it to his current one.) Suggestions? Or do I have to go do all the changes again? -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford

4 18

and now...
by Lou Burnard 15 Dec '15

15 Dec '15

If we're reaching consensus on the meta-question of how issues should be labelled, could we now collectively consider at least some of the urgent outstanding issues themselves? In particular, I am still waiting for an explicit green light from at least one other council member who has successfully built using the lb42-pure-odd-2 branch? Martin set up a Jenkins job to do this, but it seems to have fallen over at the penultimate hurdle, and I don;'t know enough about Jenkins to see why. If we get that, then I could maybe issue a pull request (whatever that is) and get this stuff merged in... If we're looking for jobs for new council members to cut their teeth on, I'd be delighted to propose trying to build this branch! Much more fun than fixing a tedious bit of prose. I'd also appreciate some feedback on my ticket proposing a new anyXML element... L

5 13

Reorganizing labels on GitHub
by Raffaele Viglianti 14 Dec '15

14 Dec '15

Dear all, Elli and I spent some time this morning going through the labels on the TEI repository and discussed a new, simpler, system for organizing our tickets. Here is a spreadsheet with current labels and their proposed new name: https://docs.google.com/spreadsheets/d/1VhBYft_85F6x8J0YpGvqn-ZfIHbXqk9j8QV… We propose to have 4 higher level label categories: *component* or *tool*, *type*, *priority*, and *status. * When creating a new issue, one label from each category should be chosen. For example a new ticket about a badly misguiding example for the the "div" element would probably get these labels: "Component: Core schema" "Type: Bug" "Priority: High" "Status: Needs Discussion" There are a couple of extra labels that don't fit this system: - "sf-automigrated": identifies tickets migrated from SF. We suggest to keep it. - "SIG": identifies tickets about SIG organization (maybe we need a category for less technical discussions, "meta"?). Then we have a couple of specific questions for you: - Should we keep labels specific to each chapter in the guidelines? (e.g. MS, ND, PH, etc). We think they should go away. But if we keep them we can get group them under "Component: Guidelines", e.g. "Component: Guidelines: MS". - "sf_creator-*" tickets were introduced to facilitate finding migrated tickets by their original SF creator. Since that information is also recorded in the text of the ticket, we think they should go away. Thoughts? Many thanks for your comments - after we make some decisions here, we will also check labels in the Spreadsheets repository and implement a similar system. Best, Raff

5 19

Building the PureODD branch
by Martin Holmes 13 Dec '15

13 Dec '15

Hi all (but mainly Lou and Hugh), I notice there's a pureodd branch for the Stylesheets. Should my Pure ODD P5 build on Jenkins be using that branch of the Stylesheets rather than the dev branch? Cheers, Martin

2 2