Re: [patch 18/95] lib/list_kunit: follow new file name convention for KUnit tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hmm... sorry about this: it definitely shouldn't've happened.

I know the original patchset did have an issue (with one of the other
patches) that Andrew fixed while merging, so maybe it snuck through
while that was happening.

On Wed, Dec 16, 2020 at 2:02 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> This is complete garbage, Andrew.
>
> In this patch, you change the name in the Makefile:
>
> On Tue, Dec 15, 2020 at 8:43 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > Subject: lib/list_kunit: follow new file name convention for KUnit tests
> >
> > Follow new file name convention for the KUnit tests.  Since we have
> > lib/*test*.c in a few variations, use 'kunit' suffix to distinguish usual
> > test cases with KUnit-based ones.
> ...
> > --- a/lib/Makefile~lib-list_kunit-follow-new-file-name-convention-for-kunit-tests
> > +++ a/lib/Makefile
> > @@ -350,6 +350,6 @@ obj-$(CONFIG_PLDMFW) += pldmfw/
> >
> >  # KUnit tests
> >  obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> > -obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> > +obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> >  obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> >  obj-$(CONFIG_BITS_TEST) += test_bits.o
>
> but the actual *file* isn't changed.
>
> So there is no way in hell this will build.

This is interesting, as the original patch did rename it here:
https://lore.kernel.org/linux-kselftest/20201112180732.75589-1-andriy.shevchenko@xxxxxxxxxxxxxxx/

So something's definitely more muddled than just the renames being
expanded out...

>
> The file is _actually_ renamed in patch [20/95], which claims to do
> the lib/bits_kunit stuff, but actually does both the bits _and_ the
> list_kunit stuff.

And again, that rename is not in the bits_kunit patch in the original thread:
https://lore.kernel.org/linux-kselftest/20201112180732.75589-3-andriy.shevchenko@xxxxxxxxxxxxxxx/

>
> Making things worse, your use of substandard tools means that this
> garbage shows up as a patch that is over sixteen *hundred* lines long,
> when proper tooling would hav eactually shown it as a rename.
>
> It _should_ have been about 10 lines total.  Not 1600 lines that hide
> the problem and make it really nasty to see.
>
> That 1600 lines of noise is ignoring patch [19/95], which does the
> "linear_ranges_kunit" renaming, adding another ~500 lines of illegible
> garbage to my mailbox.
>
> At least that one got the Makefile right, although it was really hard
> to actually see that, considering how nasty and illegible the patch
> was due to renaming.
>
> Basically, I'm going to throw all these rename patches away. Not only
> were they were completely buggy, but they were also illegible because
> of your inferior tools.

Note that the three rename patches (list_kunit, linear_ranges_kunit,
and bits_kunit) were part of the same patchset as the following three
lib/cmdline{,_kunit} changes. Those don't depend on the earlier
patches, don't have renames, and seem to be fine from a cursory
glance, but the last one ([23/95]) did have some issues earlier (which
are now fixed).

>
> Don't send me any more rename patches until your tools can actually do renames.
>
>             Linus

My other thought is that this sort of patchset really makes more sense
to push through the kselftest/kunit branch anyway, as all of the
changes were really more KUnit related than anything else. Does it
make sense to re-submit this that way?

Cheers,
-- David




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux