Live data from Hacker News

“Please don't waste maintainers' time on your KPI grabbing patches”

lkml.org

41–50 of 277 posts

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#42
post #30

I see that these "cleanup" patches are not bringing much value, bust I also don't see why fixing spelling mistakes or log messages is considered as harmful, KPI boosting or not. The maintainer even said if someone else sent those patches it would be OK, but not if Huawei employees do it. If they distrust Huawei so much, why not just ban them from committing, the same way they did recently with university "security re…

It's not about security. It's about wasting reviewers' time. I too would be annoyed if someone was submitting, say, whitespace-only changes, or similar cleanup, non-functional changes - I still have to review them and my time would be better spent looking at actually meaningful changes that make the product better. It's OK if someone is just learning the ropes with an easy change, but this seems to be more like peopl…

I think the proper way to do a “cleanup” patchset is to communicate with the maintainer beforehand and ask them what they’d prefer

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#43
post #17

Earlier quoted context omitted.

These small patches create some overhead for maintainers. He actually said in the follow up message that grouping them together is fine. 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.

I understand the overhead, but it seems like bundling lots of unrelated cleanup fixes into one large commit would make it easier to sneak in something nefarious.

They’re still going to be reviewed, and if the cover letter says “typo fixes” and one of the patches fixes more than a typo, that would be an instant red flag. A single bigger patch set is faster and easier to review.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#45
post #25

I see that these "cleanup" patches are not bringing much value, bust I also don't see why fixing spelling mistakes or log messages is considered as harmful, KPI boosting or not. The maintainer even said if someone else sent those patches it would be OK, but not if Huawei employees do it. If they distrust Huawei so much, why not just ban them from committing, the same way they did recently with university "security re…

Right? I am not really sure I see the problem. It seems to me like Huawei is just submitting clean-up patches and the maintainer has higher expectations of what patches they should be submitting. Granted I am not a developer not a maintainer of any project so that might be why it is not obvious.

If there’s a pattern of them submitting a ton of these kind of patches, that could be viewed as gaming a metric. Huawei might, for example, be assessing kernel developer performance partially on # of upstreamed commits, and I guess that’s what is being suggested here.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#46
There is an old story of two surgeons - one with a near zero patient death rate and one with a much higher patient death rate. But the surgeon with the higher death rate is tackling harder more complex surgery on sicker patients - while the other avoids the complex stuff.

There is nothing wrong with either.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#47
post #17

Earlier quoted context omitted.

These small patches create some overhead for maintainers. He actually said in the follow up message that grouping them together is fine. 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.

I understand the overhead, but it seems like bundling lots of unrelated cleanup fixes into one large commit would make it easier to sneak in something nefarious.

I think the general idea would be something like, "Fix spelling errors in log messages" and bundle several changes that do that.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#48

I see that these "cleanup" patches are not bringing much value, bust I also don't see why fixing spelling mistakes or log messages is considered as harmful, KPI boosting or not. The maintainer even said if someone else sent those patches it would be OK, but not if Huawei employees do it. If they distrust Huawei so much, why not just ban them from committing, the same way they did recently with university "security re…

When people make trivial typo PRs on my open source projects I say thanks very much, close their PR, and make the change in a commit under my name. This way, if their interest is in improving the project then it worked. And if their interest is in contributions then it works also because it doesn't pollute their contribution history with trivial changes that aren't real contributions.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#49

I see that these "cleanup" patches are not bringing much value, bust I also don't see why fixing spelling mistakes or log messages is considered as harmful, KPI boosting or not. The maintainer even said if someone else sent those patches it would be OK, but not if Huawei employees do it. If they distrust Huawei so much, why not just ban them from committing, the same way they did recently with university "security re…

I think the concern here is that at huawei there's some kernel patch metric, or incentive, or something like that. And following Goodhart's law... "When a measure becomes a target, it ceases to be a good measure."

So now there's a target that costs maintainers time, possibly lots of time, and costs huawei nothing.

There's really no control here to dial it back other than to ask 'please don't do this'.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#50
post #17

Earlier quoted context omitted.

These small patches create some overhead for maintainers. He actually said in the follow up message that grouping them together is fine. 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.

I understand the overhead, but it seems like bundling lots of unrelated cleanup fixes into one large commit would make it easier to sneak in something nefarious.

All parts of the patch have to be reviewed regardless. It just saves one session startup/tear down per patch.
Post reply on HN