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

[Richard Palethorpe]

Hello,

"xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com> writes:

> Hi!
>> Hi!
>>>> +* 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 it can be reverted in later rc if
>>>> problematic).
>>>
>>> What is the concern? All I can see is that we merge a test which is for
>>> a feature that is never included
>>
>> Not only that, the interface may change subtly.

That can always happen as plenty of changes will break LTP test
expectations, but not real programs.

>>
>>> 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).
>>>
>>> If a test requires a kernel config which doesn't exist in mainline we
>>> could also look for that automatically.
>>
>> 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.
>>

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.

My main concern is this will throw up a barrier to motivated
contributors working on the cutting edge.

-- 
Thank you,
Richard.