Jakub Kicinski <kuba@xxxxxxxxxx> writes: > On Thu, 6 Mar 2025 19:22:49 +0100 Matthieu Baerts wrote: >> > +Co-posting selftests >> > +-------------------- >> > + >> > +Selftests should be part of the same series as the code changes. >> > +Specifically for fixes both code change and related test should go into >> > +the same tree (the tests may lack a Fixes tag, which is expected). >> >> Regarding the Fixes tag in the tests, could we eventually suggest using >> the same one as for the code change? >> >> Sometimes, I do that to get the corresponding test backported as well, >> if there are no conflicts. That's good to have an easy way to check if >> something has been correctly fixed on stable versions as well. > > Hm, that's probably up to the stable team to decide. My intuition > is to reserve Fixes tags for fixes, and add another tag if necessary. +1 You could consider something like "Tests: xxx", but the problem is that not every fix will perfectly map to a test, and as noted below, it is possible that the fixes don't merge cleanly. I don't know if there would be a good tag that makes sense, really. > The mention of the Fixes tag was primarily because of NIPA checks... > A bit of a wink and a nod since we try not to speak about NIPA checks. > >> The only thing is with the selftests written in Python or Bash: it is >> easy to get a situation where there are no conflicts, but the >> modification doesn't work, e.g. some functions or variables are not >> available, etc. The stable team will then not notice that during their >> build tests. Not sure if my suggestion is safe to recommend then. I also would note that I like the approach where the test cases detect if the condition is even possible and [SKIP] if it isn't. The reason is that we can then run the latest and greatest copies of the selftest suite against even older kernels. Reality, it is not always possible to do that either - so it probably needs to be case-by-case basis anyway. > Good point..
