Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are the "thin blue line" that is trying to keep the code high quality

lore.kernel.org

Post reply on HN
Print view View original

71–80 of 186 posts

Re: We are the "thin blue line" that is trying to keep the code high quality

#71

Post by ambicapter »

mouse_ wrote: post #38
thayne wrote: post #26

> But what isn't appreciated, is that it is precisely because people who are long-term members of the community are trusted to stick around and will support code that the have sponsored. Ok. But if you make it too difficult for new developers to contribute, and the experience too stressful, then no one new will stick around to be long time maintainers, and when the old ones retire or die, there won't be anyone to rep…

The whole community shows symptoms of organizational sabotage. https://files.catbox.moe/u6rold.png

Sabotage or just the inevitable ways that organizations tend to decay (not that they have to, but if they do it tends to look a certain way).

Re: We are the "thin blue line" that is trying to keep the code high quality

#72

Post by shae »

thayne wrote: post #26

> But what isn't appreciated, is that it is precisely because people who are long-term members of the community are trusted to stick around and will support code that the have sponsored. Ok. But if you make it too difficult for new developers to contribute, and the experience too stressful, then no one new will stick around to be long time maintainers, and when the old ones retire or die, there won't be anyone to rep…

I tried to help with the Linux kernel once in 2001 or so. I decided my calm was worth more than dealing with abrasive kernel devs.

Re: We are the "thin blue line" that is trying to keep the code high quality

#73

Post by chris_wot »

llm_trw wrote: post #37
Diggsey wrote: post #36

Earlier quoted context omitted.

Noone's asking the maintainers to make the project happen. It is the maintainers job to determine whether a project should be pursued at all. If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer! That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent de…

>Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.

They can absolutely block you if the code is not good enough. But if they don't want to accept the code at all, then just say from the outset "I'm not accepting rust code", rather than waste everyone's time.

Re: We are the "thin blue line" that is trying to keep the code high quality

#74

Post by yuliyp »

ysofunny wrote: post #55
WhyNotHugo wrote: post #44

Earlier quoted context omitted.

The kernel is continuously changing (which IMHO is also an issue), so keeping a fork requires a lot of work to continuously adapt to those changes. This is why forks made for specific devices are seldom updated for more than a few months (or a couple of years if you're very lucky).

maybe we need something better than git. meh. I feel like this problem should have a technical solution. maybe a VCS good enough that this isn't as big an issue? (along the lines of pijul?) or maybe something from formal verification methods to better enforce or more clearly explain why some drivers cannot be accepted. then again, I don't think the computer science is quite there yet

The VCS has nothing to do with it. Code has all sorts of subtle dependencies. When changes are made, other things are liable to break. When they're in someone else's fork, the person making the change is obviously not going to make sure that fork will stay working.

Either the change is accepted upstream meaning that everyone else making changes to the mainline needs to keep it working, or it isn't and they don't.

Re: We are the "thin blue line" that is trying to keep the code high quality

#75

Post by muamoe »

jemmyw wrote: post #62
llm_trw wrote: post #37

Earlier quoted context omitted.

>Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.

Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintain…

Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.

Re: We are the "thin blue line" that is trying to keep the code high quality

#76

Post by markhahn »

arjie wrote: post #19

The factors at play are all obvious. The old-school guys want to keep things old-school. The new-school guys want to make things better in a new way. Has there been any new rewrite without a BFDL who himself is of the new school? The vim/neovim schism happened and perhaps that's how it ends. I personally like Neovim and I'm glad to be in backers.md and it's a tremendously larger amount of work than to have just chang…

if your lens is old-bad vs new-good, you are blind to merits.

didn't the good egcs stuff get merged after all?

Re: We are the "thin blue line" that is trying to keep the code high quality

#77

Post by muamoe »

ysofunny wrote: post #55
WhyNotHugo wrote: post #44

Earlier quoted context omitted.

The kernel is continuously changing (which IMHO is also an issue), so keeping a fork requires a lot of work to continuously adapt to those changes. This is why forks made for specific devices are seldom updated for more than a few months (or a couple of years if you're very lucky).

maybe we need something better than git. meh. I feel like this problem should have a technical solution. maybe a VCS good enough that this isn't as big an issue? (along the lines of pijul?) or maybe something from formal verification methods to better enforce or more clearly explain why some drivers cannot be accepted. then again, I don't think the computer science is quite there yet

Maintaining a fork is not difficult because we haven't invented the right VCS.

Re: We are the "thin blue line" that is trying to keep the code high quality

#78

Post by paulddraper »

krapp wrote: post #60
paulddraper wrote: post #42

Earlier quoted context omitted.

> Police don’t serve the community Whom do they serve?

Capital. Within capitalist societies police protect the interests of the state, which itself exists to serve and benefit the capitalist class. Police "maintain order" to ensure the proletariat continues to submit to the state and participate in the capitalist machine, and they commit violence against anyone who does otherwise.

Bro, just don't rob CVS

Re: We are the "thin blue line" that is trying to keep the code high quality

#79

Post by muamoe »

chris_wot wrote: post #70

I would be more likely to want to listen to T'so if he hadn't done the following: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s There was a reasonable discussion about Rust, and then T'so drops the bombshell: "I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by Rust and the reality is that ain't going to happen because we have 50 plus file sy…

Maybe they're tired of the Rust Evangelism Strike Force.
Post reply on HN