On 10/7/19 8:40 AM, Steven Rostedt wrote:
On Sun, 6 Oct 2019 10:18:11 -0700
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
Well, one thing we *can* do is if (a) if we can create a kselftest
branch which we know is stable and won't change, and (b) we can get
assurances that Linus *will* accept that branch during the next merge
window, those subsystems which want to use kself test can simply pull
it into their tree.
Yes.
At the same time, I don't think it needs to be even that fancy. Even
if it's not a stable branch that gets shared between different
developers, it would be good to just have people do a "let's try this"
throw-away branch to use the kunit functionality and verify that
"yeah, this is fairly convenient for ext4".
It doesn't have to be merged in that form, but just confirmation that
the infrastructure is helpful before it gets merged would be good.
Can't you just create an ext4 branch that has the kselftest-next branch
in it, that you build upon. And push that after the kunit test is
merged?
In the past I've had to rely on other branches in next, and would just
hold two branches myself. One with everything not dependent on the other
developer's branch, and one with the work that was. At the merge
window, I would either merge the two or just send two pull requests
with the two branches.
I do something similar when I am working on top of a branch that isn't
already in the mainline. In any case, repeating myself
Let's work on top of - it is rebased to 5.4-rc1 and ready for use.
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=test
Let's use that for kunit work for 5.5. I won't add any kselftest patches
to it and keep it dedicated for kunit work. When tests are ready for
upstream, I can keep adding them to this branch.
thanks,
-- Shuah
