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

21–30 of 186 posts

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

#21

Post by jdlshore »

theden wrote: post #17
foxes wrote: post #4

Calling yourself the “thin blue line” like a reference to police really doesn’t seem like a way to have an enduring community. Police don’t serve the community; I guess they think in the same way then.

I agree with you, and the reference _is_ politically loaded ( https://en.wikipedia.org/wiki/Thin_blue_line ): >The thin blue line U.S. flag has been banned by some police departments in the United States for its associations with ideologies described as "undemocratic, racist, and bigoted." >According to a 2018 law review article, "thin blue line" also refers to an unwritten code of silence used to cover up police mis…

Seems like ignorance of the implications, not any desire to a tie themselves to a political stance. I think the “assume positive intent” principle needs to apply here.

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

#22

Post by lexandstuff »

jdlshore wrote: post #21
theden wrote: post #17

Earlier quoted context omitted.

I agree with you, and the reference _is_ politically loaded ( https://en.wikipedia.org/wiki/Thin_blue_line ): >The thin blue line U.S. flag has been banned by some police departments in the United States for its associations with ideologies described as "undemocratic, racist, and bigoted." >According to a 2018 law review article, "thin blue line" also refers to an unwritten code of silence used to cover up police mis…

Seems like ignorance of the implications, not any desire to a tie themselves to a political stance. I think the “assume positive intent” principle needs to apply here.

Also, if you're not from the USA, you're more likely to associate it with the beloved Rowan Atkinson sitcom.

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

#23

Post by Mr_Bees69 »

Gigachad wrote: post #20
ysofunny wrote: post #3

why cannot more people learn about git and branching you want your merges in? patch it in your own branch the real crux of the issue is the quality of " the offical version", the real issue, then, is about official branding. I remember back in the day there were multiple kernel versions by different mantainers.... then again I'm probably missing the forest for the trees or something

Because forked kernels is how we ended up with all those SBCs which could only run some ancient version of linux. If you can't mainline it, you are committing to maintaining a fork forever, and the more changes you require, the more maintenance that fork will be. The Linux kernel quite intentionally makes maintaining a fork a pain in the ass to pressure vendors to mainline their drives. But now mainline maintainers a…

Upstreaming to linux-zen might work, not a kernel dev tho.

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

#25

Post by [deleted] »

beeflet wrote: post #16
jfbfkdnxbdkdb wrote: post #12

Earlier quoted context omitted.

There is redox os

It's a cool idea but it's licensed MIT instead of GPL or something copyleft so I won't contribute to it. Rust-only ecosystem would be pretty cool though. It may be worth just forking linux for the sake of compatibility, and keeping the license going. I don't see a future otherwise. I'd also like to see better compiler diversity. Maybe once gccrs rolls around we will see different attitudes around rust emerge, compare…

[deleted]

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

#26

Post by thayne »

> 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 replace them.

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

#27

Post by jf »

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again.

This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all

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

#28

Post by OJFord »

lexandstuff wrote: post #22
jdlshore wrote: post #21

Earlier quoted context omitted.

Seems like ignorance of the implications, not any desire to a tie themselves to a political stance. I think the “assume positive intent” principle needs to apply here.

Also, if you're not from the USA, you're more likely to associate it with the beloved Rowan Atkinson sitcom.

Or the non-politically-loaded phrase that the sitcom is named for.

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

#29

Post by polishdude20 »

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…

Same thing happening with ham radio.

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

#30

Post by Diggsey »

jf wrote: post #27

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know , through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. This was painful for me to read as someone who has seen how corporations think about “Open Sou…

He's not wrong, but he hasn't addressed the problem:

Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed.

On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead.

The Linux kernel maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time.

Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.

Post reply on HN