Hacker News Reader

Comment by Diggsey | Hacker News Reader

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 decision regarding R4L.

View on HN

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

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.

I think that being open to working with others is implicit in deciding to maintain a widely used project like Linux. There's tons of open source tools which are explicit "this is something you are free to use but I created it for my own purposes and don't intend to support it"; however, that isn't how Linux presents itself.

That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.

They don't owe me anything, I don't work on it and have no oar in one way or the other. I'm sure they don't give a fuck about any of these conversations. Still, I owe you nothing and I can put forth my opinion, as can you.

Can you show where it says maintainers are entitled to be free from criticism on the internet?

Can you show where it says those who criticize are entitled to be listened to on the internet?

It works both ways. If you have a beef, don't be surprised if someone responds to it in a way you don't expect or like.

Maintainers are gatekeepers. If parties on either side of the gate aren't accomplishing what they want/need, they naturally look at the gatekeeper. If both sides of the gate agree that the gatekeeper has become problematic, discussions popup to remedy the situation.

So far, I haven't seen discussions from both sides of the wall. But I hear a lot of noise from one side of the wall trying to get the attention of people on the other side of the wall. Now we will see if the people inside the wall think there is an issue with the gate.

Basic communication/decisionmaking by the maintainers about a major feature in the kernel is something that I would expect devs to be entitled to.

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

One of the big turning points of this drama was a maintainer from a different area (who had been CCed on the threads, but was not the person the patch was being submitted to) blocking a patch that they weren't going to have to maintain.

He NACKed the patch. Blocking the pack would mean that he is in a position where that NACK is final, which isn't clear at all. If that isn't the case then the NACK is only an opinion that it's a bad idea.

But saying that he is't going to have have any additional maintenance burden just because the rust code using his subsystem is in a different subtree is also not an honest assesment of the situation. That's not how the kernel developent works.

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

Then say that. A big part of the issue is that there has been mixed signals from the Linux maintainers about R4L. Linus seemed to have supported it, and others are trying to block it.

The maintainers should get on the same page about the inclusion of rustlang code, and communicate that.

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.

Reply on news.ycombinator.com