Linus Torvalds Asks Kernel Developers To Write Better Git Merge Commit Messages

[uxmkt]

>>>Linus Torvalds asked that the kernel maintainers do a better job moving forward with their commit messages
>>Been telling that to devs for years. Newsflash, the devs are still winning
>Those who do, decide
Well, I kind of disagree. Everyone has some specialization and is unmatched in a specific field. It is very uncommon for someone to be procificent in all trades.
That's why we at work have a team of specialists working together.

The meritocracy statement ("those who do, decide") is not about delineating one specialist from another (such as coder and documenter); it is about delineating specialists from the heckling peanut gallery.

[reba]

I know what agile means, I was just telling you how I see it "implemented". We don't even have clients in the sprint demo, they barely have an idea about what's coming.

That's ... bad. For everyone. Whoever is responsible should be educated or swapped out, they are a danger for the project and the company. Sorry, mate.

[bug77]

That's not my experience.

"Half-baked" - yes and no.
Yes, it is ready because funds have run out and the client's product manager got all the stuff he could get, in the prioritized order. Non-Agile could not have achieved more, probably less.
No. Because funds are finite and everything of importance has been implemented. Same reasoning as above. There is always more to do and purple unicorns to have. But a project has to end somewhere.

If the product is not deemed "ready" by the client, then prioritazion (sp?) was not correct, the implementing team was underperforming, too strict funds or bad management (priorities shifted too much thus the wrong things got implemented). So most of these come back to the client, not the team.

Agile does in no case and any way mean "do what you want" or "chaos", who ever gave you that thought?

I know what agile means, I was just telling you how I see it "implemented". We don't even have clients in the sprint demo, they barely have an idea about what's coming.

[reba]

Except that, ime, "agile" translates to "I will do whatever the hell I want" which, of course, translates to chaos. So instead of releasing whatever is ready (as agile would have you do), you end up releasing half-baked implementations.

That's not my experience.

"Half-baked" - yes and no.
Yes, it is ready because funds have run out and the client's product manager got all the stuff he could get, in the prioritized order. Non-Agile could not have achieved more, probably less.
No. Because funds are finite and everything of importance has been implemented. Same reasoning as above. There is always more to do and purple unicorns to have. But a project has to end somewhere.

If the product is not deemed "ready" by the client, then prioritazion (sp?) was not correct, the implementing team was underperforming, too strict funds or bad management (priorities shifted too much thus the wrong things got implemented). So most of these come back to the client, not the team.

Agile does in no case and any way mean "do what you want" or "chaos", who ever gave you that thought?

[bug77]

And this is the correct way to do it: release whatever. At least for agile products where the client sends a product owner which has a say in what the client needs to be done and in which priority.
If a feature is missing or if the product is not reliable or whatever, it is the product owners, and thus the clients, fault, to have not prioritized correctly in the sense of "correctly" meaning what is most important to the client.
At the end of the budget it is the client's responsibility to have a product they wanted.
And "end of budget" always happens before "we cannot think of anything more".

Except that, ime, "agile" translates to "I will do whatever the hell I want" which, of course, translates to chaos. So instead of releasing whatever is ready (as agile would have you do), you end up releasing half-baked implementations.

[reba]

Until the higher-ups come screaming "release whatever, otherwise client X walks"

And this is the correct way to do it: release whatever. At least for agile products where the client sends a product owner which has a say in what the client needs to be done and in which priority.
If a feature is missing or if the product is not reliable or whatever, it is the product owners, and thus the clients, fault, to have not prioritized correctly in the sense of "correctly" meaning what is most important to the client.
At the end of the budget it is the client's responsibility to have a product they wanted.
And "end of budget" always happens before "we cannot think of anything more".

[reba]

Those who do [the work], decide [how to do it].

Well, I kind of disagree.
Everyone has some specialization and is unmatched in a specific field. It is very uncommon for someone to be procificent in all trades.
That's why we at work have a team of specialists working together. What is easy for one is difficult or new for someone else.
This includes test concepts, workflow design, pipelining, etc.
What I want to say is, when someone is good at A it does not mean they should be doing B (alone) if it's not their strong suit (and someone else more procifient is available).
So those who do the work, are not necessarily those who decide how to do it, what to do and in which way, because it might not be their strongest skill.
Being good at racing does not make you a good team manager or mechanic. You don't get to decide here, for obvious reasons.

[bug77]

Those who do [the work], decide [how to do it].

Until the higher-ups come screaming "release whatever, otherwise client X walks"

[coder]

As i have always said, the GPL, and the software released under that license, is based on leftist, socialist, commie ideals, and it's evident in their desire to control how the code is used and what language is used to describe it.

This isn't something you'd say, if you actually had a decent amount of experience working on big software projects. For any software project of significant scale, you want to have some policies and standards to establish some degree of regularity, uniformity, and quality. I say this having spent the vast majority of my career working on closed source, proprietary software. So, don't conflate this with any sort of "commie" or open source ideology.

I would say why doesn't Linus go plow himself, but I think I will follow his advice and say he should go play hide the salami with himself.

What a douche he is.

Wow, such class.

[coder]

Isn't this potentially an actual use case for LLMs? I mean formatting and correcting grammar in a commit message to be overall consistent should be something to solve automatically, right?

I think it would be fine to have a tool that suggested an alternate phrasing, but you'd definitely want a human maintainer to read it and approve. The risk of using unsupervised rewriting is that some important details are lost or that the rewrite is factually inaccurate.

In any case, it's definitely better just to have the original authors use a clearer voice.