Re: [Tei-council] circular build headache suggestion

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