Thread (19 messages) 19 messages, 8 authors, 2022-01-05

Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality

From: Petr Vorel <pvorel@suse.cz>
Date: 2021-12-15 10:52:50

Hi Richie, all,
Hello,
Cyril Hrubis [off-list ref] writes:
quoted
Hi!
quoted
quoted
quoted
quoted
The issue is we may forget to merge patch sets for features which are
included (a far worse result). It's more stuff waiting around in the
queue. At the least we should have a procedure for tracking them (like
tagging github issues for review at each mainline release).
quoted
quoted
quoted
quoted
quoted
If a test requires a kernel config which doesn't exist in mainline we
could also look for that automatically.
quoted
quoted
quoted
quoted
The main issue is that if we happen to release LTP meanwhile with a test
for a syscall that didn't get included in the mainline in the end we
have released LTP that is supposed to be stable and the test will start
to fail when the syscall number is allocated for something else which
will happen sooner or later.
I know a example that is quotactl_path syscall.
quoted
quoted
If the real issue is LTP releases, then why not exclude tests for new
features from them? I assume it's only a small number of commits which
would need to be removed. Possibly we could tag them in git when merging
so it is not a lot more work for whoever does the release (namely
Cyril) to create a branch without them.
quoted
That sounds too complex for a test or two we are usually getting during
the release cycle.
quoted
Note that people who contribute the functionality to the kernel are used
to wait for next release window, kernel releases are aprox. twice as
fast as LTP.
quoted
quoted
My main concern is this will throw up a barrier to motivated
contributors working on the cutting edge.
quoted
So far really nobody complained, which may not be a good metric. But
still unless there is a evidence that this happens I wouldn't consider
spending effort on this.
OK, well if it comes up again we can revisit it. However Petr please
could you add the reasoning about not adding unstable tests into
releases.
Isn't "... because it can be reverted in later rc if problematic" enough?
If not what would you add? Cyril posted test getting released in LTP and later
unstable. I could be more verbose, but not sure if that's better:

* Tests for new functionality in mainline kernel should be merged after final
  release of kernel which contains that functionality. It's not enough when the
  feature gets into rc1, because in later rc the functionality can be changed or
  even reverted if problematic. And this could lead to broken test.
With that you can add
Acked-by: Richard Palethorpe <redacted>
Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help