* Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) @ 2021-06-18 6:31 Qu Wenruo 2021-06-21 10:56 ` Leizhen (ThunderTown) 2021-06-21 15:28 ` Christoph Hellwig 0 siblings, 2 replies; 5+ messages in thread From: Qu Wenruo @ 2021-06-18 6:31 UTC (permalink / raw) To: Linux Kernel Mailing List, linux-btrfs, Leizhen (ThunderTown) Hi Leizhen, and guys in the mail list, Recently I find one patch removing a debug OOM error message from btrfs selftest. It's nothing special, some small cleanup work from some kernel newbie. But the mail address makes me cautious, "@huawei.com". The last time we got some similar patches from the same company, doing something harmless "cleanup". But those "fixes" are also useless. This makes me wonder, what is really going on here. After some quick search, more and more oom error message "cleanup" patches just show up, even some misspell fixes. It's OK for first-time/student developers to submit such patches, and I really hope such patches would make them become a long term contributor. In fact, I started my kernel contribution exactly by doing such "cleanups". But what you guys are doing is really KPI grabbing, I have already see several maintainers arguing with you on such "cleanups", and you're always defending yourself to try to get those patches merged. You're sending the patch representing your company, by doing this you're really just damaging the already broken reputation. Please stop this KPI grabbing behavior, and do real contribution to fix the damaged reputation. Thanks, Qu ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) 2021-06-18 6:31 Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) Qu Wenruo @ 2021-06-21 10:56 ` Leizhen (ThunderTown) 2021-06-21 11:40 ` Qu Wenruo 2021-06-21 15:28 ` Christoph Hellwig 1 sibling, 1 reply; 5+ messages in thread From: Leizhen (ThunderTown) @ 2021-06-21 10:56 UTC (permalink / raw) To: Qu Wenruo, Linux Kernel Mailing List, linux-btrfs Hello, Qu: My contributions to the kernel in the past have mainly been on optimizing the performance of the ARM64 SMMU driver, including the iova optimization, strict mode optimization, and the lazy mode optimization. Also working on the development of some ARM SoC drivers. When time and effort is allowed, I also contribute to other modules of Linux kernel, trying to find something can be improved, and some cleanup work is being done. In the future, I will continue to make more and more important contributions to the Linux community. Thanks. Zhen On 2021/6/18 14:31, Qu Wenruo wrote: > Hi Leizhen, and guys in the mail list, > > Recently I find one patch removing a debug OOM error message from btrfs selftest. > > It's nothing special, some small cleanup work from some kernel newbie. > > But the mail address makes me cautious, "@huawei.com". > > The last time we got some similar patches from the same company, doing something harmless "cleanup". But those "fixes" are also useless. > > This makes me wonder, what is really going on here. > > After some quick search, more and more oom error message "cleanup" patches just show up, even some misspell fixes. > > > It's OK for first-time/student developers to submit such patches, and I really hope such patches would make them become a long term contributor. > In fact, I started my kernel contribution exactly by doing such "cleanups". > > But what you guys are doing is really KPI grabbing, I have already see several maintainers arguing with you on such "cleanups", and you're always defending yourself to try to get those patches merged. > > You're sending the patch representing your company, by doing this you're really just damaging the already broken reputation. > > Please stop this KPI grabbing behavior, and do real contribution to fix the damaged reputation. > > Thanks, > Qu > > > . > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) 2021-06-21 10:56 ` Leizhen (ThunderTown) @ 2021-06-21 11:40 ` Qu Wenruo 0 siblings, 0 replies; 5+ messages in thread From: Qu Wenruo @ 2021-06-21 11:40 UTC (permalink / raw) To: Leizhen (ThunderTown), Qu Wenruo, Linux Kernel Mailing List, linux-btrfs On 2021/6/21 下午6:56, Leizhen (ThunderTown) wrote: > Hello, Qu: > > My contributions to the kernel in the past have mainly been on optimizing the performance of the ARM64 SMMU driver, > including the iova optimization, strict mode optimization, and the lazy mode optimization. Also working on the > development of some ARM SoC drivers. You indeed have done solid contribution to the kernel in the past, thus better could have been done. > > When time and effort is allowed, I also contribute to other modules of Linux kernel, trying to find something can be > improved, and some cleanup work is being done. I'm not saying cleanup is not important, in fact we have routinely cleanups of typos/grammar for btrfs. (And I guess mostly caused by myself?) Please at least merge all those small fixes into a larger patchset, and with a good cover letter to explain the reason (and auto-tool to do the change if possible) for all the involved maintainers, so that all of us are on the same page. > > In the future, I will continue to make more and more important contributions to the Linux community. Even without checking the git log, I can easily think of some big contributions from your employer, like EROFS and F2FS. Thus I don't have any doubt about that. If you guys just want more ideas, there are tons of better things can be done, for both newbie and veteran, which IMHO can benefit everyone in the community: - Better kernel CI/Zero-day testing One of the better example is Intel LKP, it caught quite some bugs. (although sometimes not that reproducible) If you guys could have such facility running for not only upstream kernels but also maintainers' trees, I have no doubt it will be well received. - BUG_ON() removal I'm pretty sure there are quite some code using BUG_ON() to handle errors, especially for -ENOMEM (just handled a dozen in btrfs). Can't imagine a maintainer don't like this (of course with proper commit message) - Error injection tests Especially when combined with above BUG_ON() removal. Any everyone can also learn some tricks from BCC community. - Better code refactor for super long parameter lists/super deep loops I'm definitely not referring functions like submit_extent_page(). Although if anyone has better way to refactor such functions, it would definitely be a good move. - More comprehensive metadata check for various filesystems Not sure about other fses, as they have much less metadata usage. But we have almost member by member check for all metadata, it may be an interesting idea to enhance other filesystems too. - More upstream phone/tablet support Especially for guys even running upstream kernel on RPI CM4 like me, more ARM devices with upstream kernel support will just be more happiness. Not to mention this also means super long time support, way longer than the lifespan of those devices. It's super sad to see just less than a dozen phones/tablets got upstream kernel support. Even more frustrating that those mainlined devices are already pretty old and slow for today's standard. If you guys can change the trend, it would be wonderful. - More testing on extra page size Well, this is more or less related to my personal work, testing btrfs subpage support on 64K page sized Aarch64 platforms. Despite of my impure motivation, tests on new page size would definitely help everyone. (Looking at some M1 chips which doesn't even support 64K page size at all) Thanks, Qu > > Thanks. > Zhen > > On 2021/6/18 14:31, Qu Wenruo wrote: >> Hi Leizhen, and guys in the mail list, >> >> Recently I find one patch removing a debug OOM error message from btrfs selftest. >> >> It's nothing special, some small cleanup work from some kernel newbie. >> >> But the mail address makes me cautious, "@huawei.com". >> >> The last time we got some similar patches from the same company, doing something harmless "cleanup". But those "fixes" are also useless. >> >> This makes me wonder, what is really going on here. >> >> After some quick search, more and more oom error message "cleanup" patches just show up, even some misspell fixes. >> >> >> It's OK for first-time/student developers to submit such patches, and I really hope such patches would make them become a long term contributor. >> In fact, I started my kernel contribution exactly by doing such "cleanups". >> >> But what you guys are doing is really KPI grabbing, I have already see several maintainers arguing with you on such "cleanups", and you're always defending yourself to try to get those patches merged. >> >> You're sending the patch representing your company, by doing this you're really just damaging the already broken reputation. >> >> Please stop this KPI grabbing behavior, and do real contribution to fix the damaged reputation. >> >> Thanks, >> Qu >> >> >> . >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) 2021-06-18 6:31 Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) Qu Wenruo 2021-06-21 10:56 ` Leizhen (ThunderTown) @ 2021-06-21 15:28 ` Christoph Hellwig 2021-06-21 23:39 ` Qu Wenruo 1 sibling, 1 reply; 5+ messages in thread From: Christoph Hellwig @ 2021-06-21 15:28 UTC (permalink / raw) To: Qu Wenruo; +Cc: Linux Kernel Mailing List, linux-btrfs, Leizhen (ThunderTown) WTF is KPI? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) 2021-06-21 15:28 ` Christoph Hellwig @ 2021-06-21 23:39 ` Qu Wenruo 0 siblings, 0 replies; 5+ messages in thread From: Qu Wenruo @ 2021-06-21 23:39 UTC (permalink / raw) To: Christoph Hellwig, Qu Wenruo Cc: Linux Kernel Mailing List, linux-btrfs, Leizhen (ThunderTown) On 2021/6/21 下午11:28, Christoph Hellwig wrote: > WTF is KPI? > https://en.wikipedia.org/wiki/Performance_indicator Not something open-source contributors should really care. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-21 23:39 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-18 6:31 Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk) Qu Wenruo 2021-06-21 10:56 ` Leizhen (ThunderTown) 2021-06-21 11:40 ` Qu Wenruo 2021-06-21 15:28 ` Christoph Hellwig 2021-06-21 23:39 ` Qu Wenruo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).