On Wed, Jan 15, 2025 at 02:41:31PM +0900, Michael Paquier wrote: > On Tue, Jan 14, 2025 at 11:48:28AM -0800, Noah Misch wrote: > > I misunderstood, and I was mistaken to see this as a bug fix. The > > isolationtester is acting per its definition, and this would be a definition > > change. Do others have opinions on the merits of today's definition vs. the > > proposed definition? > > I agree that Michail's case with the handling of the markers is kind > of strange in the case he has reported. Anyway, do you think that it > would be a good idea to change that knowing for how long we've relied > on isolationtester to do things the way they are?
I think that would depend on what proposed tests become easier. Since the original poster used the "notices" marker type to solve the motivating use case, let's shelve this until there's new demand. If we ever unshelve this and find much in today's specs that would malfunction under the new definition, we might offer both definitions. A new marker syntax would reach the new definition, and old specs would work as before. > If we do it only on > HEAD, it would make the back-patching of newly-added tests for bug > fixes potentially more complex to deal with. If applying the new > definition across all the stable branches, this could impact something > outside code :/ When I'm exposed to non-core tests, those tests usually target many major versions simultaneously. Having the spec meaning vary across major versions would hurt them more than it would help. Hence, back-patch if we do adopt the change. As above, the impact on existing specs could inform whether we add syntax vs. redefine existing syntax.
