Search Linux Wireless

Re: wireless-drivers: random cleanup patches piling up

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

 



On 01/21/2016 08:58 AM, Kalle Valo wrote:
Hi,

I have quite a lot of random cleanup patches from new developers waiting
in my queue:

https://patchwork.kernel.org/project/linux-wireless/list/?state=10&delegate=25621&order=date

(Not all of them are cleanup patches, there are also few patches
deferred due to other reasons, but you get the idea.)

These cleanup patches usually take quite a lot of my time and I'm
starting to doubt the benefit, compared to the time needed to dig
through them and figuring out what to apply. And this is of course time
away from other patches, so it's slowing down "real" development.

I really don't know what to do. Part of me is saying that I just should
drop them unless it's reviewed by a more experienced developer but on
the other hand this is a good way get new developers onboard.

What others think? Are these kind of patches useful?

Kalle,

We might get new developers, but the cost may be high. In the staging tree, things are worse. The tools can be applied in a blind fashion, but the results can be really stupid. GregKH has told a few would-be contributors to "go away" after a few patches that would not build.

As most of these patches are based on "problems" found by application of various standard tools, they will likely be resubmitted over and over until the code is "fixed". Whether the patches are useful may not be the main question.

My real complaint with these patches is that very few are more than compile tested. For example, there are 3 patches for memory leaks in b43. One (https://patchwork.kernel.org/patch/7998941) was rejected because it missed some such leaks, but there was not a formal NACK. The patch was fixed and resubmitted (https://patchwork.kernel.org/patch/8014311/), but not yet tested. The author then resent it (https://patchwork.kernel.org/patch/8049041/) and was chastised for resending as it still had not been tested. Of course, the first two of these can be dropped. Unfortunately, there are very few devs who have the necessary hardware to test.

Most of the current set do not account for the directory restructuring and will not apply.Those can be rejected with the appropriate message asking that they be rebased. That should not require too much of your time. That will at last clean out the current backlog.

Is it possible for us to require the patch author to supply the level of testing when that is not obvious? This information should be in the comments location after the first ---. I suspect I know the answer for non-maintainers, but the formal requirement might be helpful. I will start NACKing those patches without such information.

I also promise to be more diligent in reviewing the patches that are directed at the drivers that I maintain.

Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux