ljs

ljs, 1 day ago

@vbabka @kernellogger ;)

It's enough to see you stick up for kernel devs Thorsten when people engage in the usual attacks (people learned nothing from the XZ thing), we can disagree on things like CVEs but you show spine where it counts :>)

ljs, 4 days ago

@janriemer @chriskrycho Spot on!

As I'm (nearly done) writing a book about mm to learn mm deeply, I totally buy the 'write about it to understand' thing, as I've experienced it first hand, endlessly.

ljs, 4 days ago

@6d03 @liskin commits are smaller granularity than PRs and different scope, that doesn't work at all.

It's just laziness it's quite simple

ljs, 4 days ago

@6d03 @liskin trying to be more zen in 2024:

I respectfully disagree with this practice :)

ljs, 4 days ago

@6d03 @liskin yeah this is the 'argument', maybe I'll be less zen and tell you it's just terrible. It's not debatable, it's terrible.

Why are you even using source control?

You end up with a 10,000 line commit? No bisect now, no ability to back port, no description of the logic behind things, no separation of moving code/changing it.

I've seen somebody do a 5,000 line move of code and subtle changes in it - good luck dealing with that as one commit.

You remove all code-specific context, all things that are sub-PR level.

All for what purpose? To make life a little easier or neater?

If people can't be bothered to rebase properly, then why on earth do you think they'd put every bit of detail needed in a PR description?

It's impossible to argue these things anyway, and pointless, because those making the decisions are not the ones dealing with the consequences of this.

I've literally run into every single one of these issues in practice.

And you're commenting on a post where I literally point out the benefit of a high-granularity comment that wouldn't exist in this scheme?

Come on man.

ljs, 4 days ago

@6d03 @liskin to be clear I"m not attacking you at all :) just have strong feelings on this issue. I'm just attacking the auto-squash concept as an idea.

ljs, 3 days ago

@6d03 @liskin you're a good man for making the effort!

While I (obviously) disagree with auto-squash taking the time to really be detailed in what place you possibly can already adds a ton of value.

I think the guidelines at https://www.kernel.org/doc/html/latest/process/submitting-patches.html are relevant even for other projects (in the 'describe your changes' bit). Obviously tailor accordingly.

ljs, 20 days ago

@Di4na A very thoughtful piece, another factor I think that is often downplayed is the role of talent - the author of this piece is clearly very talented, but the number of people with enough talent in the world to work on highly complicated software like this is limited, so that adds YET ANOTHER filter on the number of people who can end up working on these things.

I think society as a whole tends to like to act as if anybody if they only want it hard enough could do these things whereas the reality is only a small fraction could.

ljs, 21 days ago

@sima @gregkh @kees @kernellogger what is the benefit in tagging 'could maybe possibly be a security issue' to commits when the definition of that is so broad? Is it really beneficial?

Note that it's not just a 'tag' but for enterprise kernels often entails (potentially significant) work in addressing CVEs?

Perhaps a metadata tag would work better? Potentially-Exploitable or such? :)

Given the controversy around CVEs that might be a lighter touch than the gradual move towards treating more and more commits as if they were known security flaws.

ljs, 21 days ago

@sima @kees @kernellogger @gregkh @airlied I don't understand, you should backport the entire subsystem constantly? How can that possibly work?

And at that point why are you tagging anything?

Forcing more people into what model?

ljs, 25 days ago

@exa I have suddenly lost all empathy for you with that post