+1 In an ideal world where we had tons of hardware to run tests and our tools were better at associating failures with particular branches or tags or something...then absolutely we should keep those jobs running. That way if the need for a 10.0.1 arises, we already have a wealth of test history there to provide confidence.
But since we don't live in that world, then those CI jobs probably aren't worth the noise and hardware-time. Thanks David! On Wed, Apr 15, 2026 at 9:43 AM David Smiley <[email protected]> wrote: > > Without further input, I'm going to disable those Jenkins jobs as soon > as tomorrow. > > On Tue, Apr 14, 2026 at 8:39 AM David Smiley <[email protected]> wrote: > > > > Does it serve us well to retain Jenkins CI jobs for branches we > > _usually_ don't bring fixes to? I'm referring to jobs for release > > branches -- 10.0, 9.10. Of course, if someone volunteers to step up > > to release 10.0.1 or 9.10.1 *then* such a person should enable such > > jobs. > > > > Jobs for 10.0 (and likely 9.10) occasionally fail for reasons that > > have already been fixed. Failed jobs are a distraction on our > > attention, polluting the build mailing list and Develocity flaky test > > reports; perhaps Fucit too. > > > > Would a "decision" / process change here go in releaseWizard.yaml? > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
