Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

[shuah]

On 10/4/19 5:10 PM, Brendan Higgins wrote:
> On Fri, Oct 4, 2019 at 3:47 PM shuah <shuah@xxxxxxxxxx> wrote:
> > On 10/4/19 4:27 PM, Brendan Higgins wrote:
> > > On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
> > > > On 10/4/19 3:42 PM, Linus Torvalds wrote:
> > > > > On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
> > > > > > This question is primarily directed at Shuah and Linus....
> > > > > >
> > > > > > What's the current status of the kunit series now that Brendan has
> > > > > > moved it out of the top-level kunit directory as Linus has requested?
> > > >
> > > > The move happened smack in the middle of merge window and landed in
> > > > linux-next towards the end of the merge window.
> > > >
> > > > > We seemed to decide to just wait for 5.5, but there is nothing that
> > > > > looks to block that. And I encouraged Shuah to find more kunit cases
> > > > > for when it _does_ get merged.
> > > >
> > > > Right. I communicated that to Brendan that we could work on adding more
> > > > kunit based tests which would help get more mileage on the kunit.
> > > >
> > > > > So if the kunit branch is stable, and people want to start using it
> > > > > for their unit tests, then I think that would be a good idea, and then
> > > > > during the 5.5 merge window we'll not just get the infrastructure,
> > > > > we'll get a few more users too and not just examples.
> > >
> > > I was planning on holding off on accepting more tests/changes until
> > > KUnit is in torvalds/master. As much as I would like to go around
> > > promoting it, I don't really want to promote too much complexity in a
> > > non-upstream branch before getting it upstream because I don't want to
> > > risk adding something that might cause it to get rejected again.
> > >
> > > To be clear, I can understand from your perspective why getting more
> > > tests/usage before accepting it is a good thing. The more people that
> > > play around with it, the more likely that someone will find an issue
> > > with it, and more likely that what is accepted into torvalds/master is
> > > of high quality.
> > >
> > > However, if I encourage arbitrary tests/improvements into my KUnit
> > > branch, it further diverges away from torvalds/master, and is more
> > > likely that there will be a merge conflict or issue that is not related
> > > to the core KUnit changes that will cause the whole thing to be
> > > rejected again in v5.5.
> >
> > The idea is that the new development will happen based on kunit in
> > linux-kselftest next. It will work just fine. As we accepts patches,
> > they will go on top of kunit that is in linux-next now.
>
> But then wouldn't we want to limit what KUnit changes are going into
> linux-kselftest next for v5.5? For example, we probably don't want to
> do anymore feature development on it until it is in v5.5, since the
> goal is to make it more stable, right?
>
> I am guessing that it will probably be fine, but it still sounds like
> we need to establish some ground rules, and play it *very* safe.

How about we identify a small number tests that can add value and focus
on them. I am thinking a number between 2 and 5. This way we get a feel
for the API, if it changes for the better great, if it doesn't have to,
then you know you already did a great job.

Does that sound reasonable to you?

thanks,
-- Shuah