Re: [tei-council] Fwd: Re: editing the TEI stylesheets

Yeah, we do need a protocol for this. I can't claim to understand the Stylesheets either, but I also don't understand our test infrastructure. For example, running "make test" in P5/ clearly runs some tests, but not all of them. I can do that and then check stuff in and have Jenkins yell at me a few minutes later. So how does one run a comprehensive suite of tests? Does it require a Jenkins install? Running the Stylesheet tests doesn't even give me a report at the end, I have to scroll back through the output to see that at least one test is failing—no surprise that it's related to making PDFs, which doesn't work outside our bespoke Linux environment. It's wonderful that there are tests, but it's terrible, and terrifying(!) that they're not generally usable. I would really like to get us into a place where normal humans (or even most Council members) could edit the Guidelines or Stylesheets and test their changes before pushing them. Jenkins is great, but it's a backstop (or feels to me like it should be, anyway). Or is this just me being an idiot? It certainly wouldn't be the first time. Does anyone else have difficulty with this stuff? I expect Stuart's pull request went past me last week while I was away at a conference. I've commented and asked him for some clarification. On Tue, Aug 18, 2015 at 6:58 PM, Martin Holmes wrote:

I looked at this, but I'm by no means confident that I could assess the impact of a merge like this without investing a fair amount of time figuring out what it does and how it works. The Stylesheets are still fairly mysterious to me, except for the bits I happen to have looked at.

I think what we actually need is a protocol for this. So, for instance, before accepting a pull request that is anything more than a typo fix, at least check out the branch and run all the regular tests; then perhaps create one more test that checks the bug that's being fixed; then go ahead and merge.

Cheers, Martin

On 15-08-18 02:52 PM, James Cummings wrote:

...

Forwarding this reminder to tei-council to remind them that they need to keep a watching eye on such pull requests. (Once set up, we should get notifications sent to tei-council if possible)

-James

-------- Forwarded Message -------- Subject: Re: editing the TEI stylesheets Date: Wed, 19 Aug 2015 09:43:31 +1200 From: Stuart A. Yeates To: James.Cummings@it.ox.ac.uk CC: Sebastian Rahtz

OK, so I sent a pull request almost a week ago https://github.com/TEIC/Stylesheets/pull/114

Do I need to notify someone? Or has feedback gone somewhere I'm missing...

cheers stuart

-- ...let us be heard from red core to black sky

On Wed, Aug 12, 2015 at 10:01 PM, James Cummings mailto:James.Cummings@it.ox.ac.uk> wrote:

Hi Stuart,

The TEI Technical Council is currently reviewing how it uses GitHub as part of examining whether it is a suitable replacement for SourceForge in moving Guidelines development there. As you know, it moved the Stylesheets (and other software) building there some time ago. Although you (and various others) are members of the Stylesheets repository I believe the correct github etiquette is to fork, then issue a pull request. However, I think as long as you are flagging that you are making the change (or open an issue and then make the change as a result of that) it should probably be fine. (Though when you say 'regularise the display of attribute values' I'd be interested to know what you mean by regularise. There are some options and logic already in there.) The change in your forked version won't get looked at by Jenkins. We're also looking at whether some of the GitHub hosted alternative continuous integration systems might replace Jenkins. So, to be honest, you could do either, but fork+change+pull-request will ensure that it gets other eyes on it before going into the system. Jenkins uses the most up-to-date stylesheets when next building the Guidelines. I know it used to email when doing commits to the Guidelines SF SVN repository that broke something (or more accurately when someone committing around the same time as you broke something ;-) ) and I'm assuming that is still the case. I don't think it emailed just when it was running a job based on your commits...just when that job failed and your commit was one of those possible causes.

That is my understanding at least, some of our council github gurus may correct me.

-James

On 12/08/15 10:26, Stuart A. Yeates wrote:

I've got a change I'd like to make to the stylesheets used to generate the HTML version of the standard (a minor change to regularise the display of attribute values), but I'm not quite sure how to go about it.

Do I just push a change request to https://github.com/TEIC/Stylesheets ? Or fork it? Does that get tested by jenkins?

Jenkins used to send me emails when it ran a job based on my commits, but I've not seen one for a couple of recent commits, is that because I'm not on the council any more?

cheers stuart -- ...let us be heard from red core to black sky

-- Dr James Cummings, James.Cummings@it.ox.ac.uk mailto:James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

--

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