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

[OneTimeShot]

The eternal battle. Passive voice is traditionally used in academic papers (all the way back to when academic papers were written in Latin).

"I took a test tube and filled it with water" vs "A test tube was taken and filled with water"

Avoiding specifying pronouns is not just a modern thing...

[coder]

Nothing controversial here,

IMO, the most noteworthy aspect is that he didn't institute some sort of policy like this, decades ago! Git has been around almost 2 decades, already. Even CVS, which I think is probably where the Kernel started out, had the concept of branches and merge commits.

[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.

[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.

[bug77]

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

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

[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.

[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".

[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]

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]

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.