Re: [Tei-council] circular build headache suggestion

comments inline …

Am 15.06.2020 um 16:30 schrieb Martin Holmes :

HI Peter,

The reason we say it's most important that the Stylesheets-dev branch needs to build against the P5-dev branch is because they will be released together, and when that happens, they must work together. If we ignore that combination and prefer to focus on keeping the Stylesheets-dev branch building against the released p5subset.xml, we'll have a problem when we release, because the released p5subset will change. Yes, but I still think it’s better to fix the Stylesheets tests *once* in the release branch rather than every time you rephrase some description in the Guidelines. My proposal (which I never ‚officially‘ submitted) for doing this would look like this: a) create release branches for Guidelines and Stylesheets b) initially build Stylesheets-release-branch against Guidelines-dev-branch; this will fail c) fix expected results in Stylesheets-release-branch and rebuild d) build Guidelines-release-branch against Stylesheets-release-branch

Changes on either side may break the other build. If you change the content model of an element, or even its description, then the crude diffing tests in the Stylesheets Tests will fail (which is what's happening now); so the Stylesheets dev build can either have its expected-results matching what you get from the released p5subset.xml, or it can have them matching the p5subset.xml from the P5-dev branch, but not both. Yes, that’s the point and we all agree: you can’t have both.

If you change the Stylesheets in any significant way, then it's likely the Glines build tests may fail because (e.g.) the HTML output has been improved so the expected-results are not the same. As I said.

Best Peter

On 2020-06-15 2:42 a.m., Peter Stadler wrote:

...

Syd, Martin, I think I’m not yet convinced that the proposed setup will be any better. For several reasons: a) you say: „it sucks“ – but what exactly sucks? aa) That we can’t have both ("tests can succeed only against either the release branch of P5 or the dev branch of P5“)? You’re not fixing that but only switching the default from ’stylesheets-dev against tei-release’ to ’stylesheets-dev against tei-dev’ ab) … because you „believe that the reverse would make a lot more sense“: Why? Can you elaborate? In fact, is there any Stylesheet test that relies on a dev version of the P5 sources – which could not be rewritten as a customization? b) I admit that the current setup is by no means ideal but to all the circularity there’s a clear way out: The current released version of p5subset.xml (which lives outside any Jenkins) serves as a seed for the Stylesheets build which then enables the Guidelines build. ba) It’s always been like this. I only added the feature to set the localsource for the Stylesheets build last year [1] when we had trouble connecting to the TEI server and resorted to fetching p5subset.xml from an alternative location (= a Jenkins server). [I take it that this is a traditionalists argument …] bb) the proposed dev-against-dev testing only introduces real circularity, I fear. Because there might be changes to the Guidelines repo that break the Stylesheets build and vice versa. (Right now, we are only able to break the Guidelines build by a change to the Stylesheets.) The latter is much more predictable: If you’re changing the ODD processing there’s a good chance that the Guidelines build is affected. On the other hand–and even more so for external contributors–it’s totally incomprehensible that a change to some element description in the Guidelines repo might break the Stylesheets build. Looking forward to the discussion :) Best Peter [1] https://github.com/TEIC/Stylesheets/commit/5c8c0d67618b6916853dbb3626e72476d...

...

Am 12.06.2020 um 16:44 schrieb Syd Bauman : The circularity of the P5 and Stylesheets builds depending on each other has bitten us once again. (Ouch!) We have a situation now where the Stylesheets tests can succeed only against either the release branch of P5 or the dev branch of P5, but not both simultaneously. This sucks. Right now Stylesheets dev branch is successfully building against P5 release[1], but failing against P5 dev branch[2]. We believe that the reverse would make a lot more sense. While it is desirable that it build against both branches, it is frequently impossible. So we have to pick one, and we (Martin & Syd) think we should pick them as follows: * P5 release branch should be built with the P5 release Stylesheets * P5 dev branch should be built with the P5 dev Stylesheets * Stylesheets release should be built against P5 release branch * Stylesheets dev should be built against P5 release dev as a general rule. This means we would have to always release a new Stylesheets the same day we release P5 every time. It also means that if we ever had a reason we needed to do an interim release of either, we would have to fight with the circularity problem (probably by trying to make sure both branches work against each other, or temporarily suppressing some finicky tests). But the advantage is that "normal" releases and updates would work properly. So what we would like to do is: * Update Stylesheets deb branch tests so that they work against P5 deb (which will break them against P5 release branch) * Have Peter & Martin agree on a consistent set of explicit job names in Jenkins that perform the 4 builds listed above. Notes ----- [1] E.g. on jenkins.tei-c job "Stylesheets-dev" and jenkins2.tei-c job "Stylesheets-dev-against-P5-release". [2] E.g. on jenkins.tei-c job "Stylesheets-dev-against-TEIP5-dev" and jenkins2.tei-c job "Stylesheets-dev-against-TEIP5-dev". _______________________________________________ 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

-- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council