"I'm getting tired of arguing with kernel maintainers."
twitter.com
twitter.com
It reveals that there are things that marcan is glossing over and forcefully pushing for his way of doing things. No wonder why the conversation with the maintainer is not going forward.
It's also not pretty how marcan is just making fun of the kernel maintainer in other tweets: https://twitter.com/marcan42/status/1587023643380682759
He is talking as if these are private conversations and forgetting that this is completely public.
I admire his efforts in bringing up Linux on Apple Silicon platforms but this attitude of making a tantrum on Twitter is just sad and not very professional. And I bet a lot of junior developers use him as a role model, which is even sadder as this kind of attitude and snarkiness just keeps propagating.
If you feel the need to escalate your view to Twitter and turn it into a one-sided view, then maybe there is a chance you are missing something out.
Perhaps you don't owe kernel maintainer foes better, but you owe this community better if you're participating in it.
> It is not my job to drag you kicking and screaming until you either give up or have a lightbulb moment.
Soooo, you're saying if I submit a 1700 line change to _your_ codebase, step into your world and "actually understand" what you're trying to do, you'll just magically _approve_ my commits, no questions asked? Sounds pretty irresponsible.
Yes, you do have to drag people kicking and screaming into your better world. They think their world is pretty neat already! Proving yours is better actually takes patience and work.
But how do the maintainers know that? They have to review and accept patches from hundreds or thousands of people. Maybe everything would be perfectly fine if they just blindly ack'd the patch from this particular author. But that is certainly not what they should just generally do.
If he is expecting his code to be reviewed at the speed of 1 line / second, that just seems really fast for kernel C. Alternatively, if he is expecting the maintainers to not understand the details of the modules, that is something I would be uncomfortable with as a maintainer. I would want to make sure that new code meets my standards and that I understand why any complexity in the code exists.
If he is expecting his involvement in the review to only take 30 minutes that's more reasonable, but for mainlining stuff from Asahi, it seems like having upstream understand what is special about M1 is probably worth your time to explain / convince.
The dude is describing his self here, he apparently doesn't bother to actually stop and think about the problem the kernel maintainers are trying to solve. He only wants his drivers to work and the world be damned.
He doesn't stop to think that they are going to have to maintain that code practically forever after he gets bored and moves on to something else.
> Like dude, if you aren't going to step into my world and actually understand what I'm trying to do here, just suck it up and ack my patch.
That's literally the opposite of what we should be doing for the Linux kernel! If someone doesn't understand what they're merging, they shouldn't +1 it. That's how we end up with garbage NTFS drivers polluting the kernel, or "University of Minnesota" attacks. Protracted discussions about architecture is how Linux has been maintained for the past 3 decades, if you need to move fast and break things Linux is not a good choice.
If you can't, quit.
The second conflict appears to have occurred around a dispute over the logical organization of the changes, and how they would be called and where the code would live. In this case, it appears the Asahi people organized it in a way that made sense based on their understanding of the hardware in question, the current structure of the code, and in a way that other parts were already laid out. A different reviewer objected to this layout, noting that while they had indeed followed the model of some other code, that was wrong and apparently shouldn't have been there in the first place. Again there appears to have been an amount of back and forth that was ultimately a series of rejections on proposed alternates without any real explanation of what they were looking for and why they thought given the hardware design, this layout didn't make sense. This argument included a directive from the reviewer to just do it "proper" without (to my reading) any real guidance to what "proper" would look like given nature of what is being submitted.
While I appreciate that reviewers don't necessarily have all the context and will be asking questions, sometimes on stuff that is answered within the file, I would certainly expect them to not return a review that is almost entirely answered by context within the file. I would equally expect that if they are going to suggest I do something a different way, that suggestion should be valid code, or at least pseudo code that can be made valid. I would honestly also expect a review to include some feedback on what the reviewer would like when the disagreements are about logical organization or coding choices that fall outside the documented code style requirements.
The author is literally maintaining a fork already https://asahilinux.org/
I do take your larger point about rubber-stamping contributions generally not being a good idea.
I mean, really, why would you bother trying to change anything as long as the hypothetical possibility exists of going elsewhere? Is there a single thing you don't like about your current circumstances? Just leave! That will definitely be better for everyone, and there definitely won't be any crippling ongoing costs that result.
> It should not take email chains that don't even fit on my screen to upstream a 1700-line patchset that implements 3 kernel modules.
> Between this and drive-by reviewers that make nitpick comments (most of which are wrong), no wonder stuff takes forever to upstream.
> It is very frustrating to have to defend it over hours/days/weeks/months ...
Regardless of the merit of these things, if this individual doesn't like it then I think it's totally appropriate to challenge them to do it better. Failing that, I'll risk erring on the thought that there are difficulties with running OSS communities that this person is downplaying.
[0] Quite possibly a victim-blaming way, though not necessarily, depending first and foremost on the merits of the complaint...
Anyway, I actually think this is rather controversial with valid opposing perspectives, so I don't intend to invalidate yours! This is just where I land.
[0]
> if this individual doesn't like it then I think it's totally appropriate to challenge [said individual] to do it better
Second: that's still a much more reasonable objection than "just fork the community", which usually has costs ranging from obnoxious to crippling. The mere attempt could destroy lots of value for no benefit, and even if it succeeds things are likely to suck for a while for everyone involved. This is not an appropriate option to push just because there's an alleged process problem. Not even if the complainer genuinely should have proposed a solution, offered to do the work, or whatever.
If Apple wanted the Macbook to have quick Linux support, they should have merged the patches themselves. When you leave the community to do a corporation's job, things don't exactly move at a fast clip.
People will bitch about that too - see what happens to kernels of Android handsets, people will complain that OEMs don’t want to waste time upstreaming drivers.
Presuming that the hacks only exist within a particular kernel module, and that that module only gets loaded when the given hardware is found, don't those hacks then only affect people with the (previously, and still mostly) unsupported hardware? Which — at least for hardware in the critical path to userland interactivity — is strictly better than their hardware not working at all?
That message thread is 15 thousand lines long - it is quite disrespectful to demand I read the whole thing without even knowing what I'm looking for. Can you at least point out the relevant parts, or - even better - copy them in a comment for all to see?
If Apple (the company with ~$200,000,000,000 in cash reserves) worked with the community here, there wouldn't be any issues here.
Eh, I get it. Understanding anything takes effort, and each one of us has a limited amount of mental energy per day. Nobody likes wasting it for what they feel is responsibility of another. I wouldn't criticize the author for what happened in the kernel discussion - I don't have enough skill or experience to understand why or how is anyone right or wrong.
What I do have a problem with, is posting an article like this on HN, then shutting every comment down with "read these 15000 lines, peasant, before you even dare to speak". Most people on HN are not kernel hackers, so why the (if I may be blunt - pretentious) gatekeeping? There must be some better way of explaining why someone's comment is wrong than "here, read this large text, figure it out yourself and don't come back until you figure it out". That's just lazy and disrespectful.
I think that I’d have preferred a detailed analysis of the hundreds of messages for one patch broken up into segments and assigned categories. For example, and this are made up:
15% of messages stemmed from mis-application of Intel/AMD assumptions to Apple Silicon.
Because doing so without naming names, in an opinionated manner, would really help make or break their point. It would also provide ground for the “read all 15,000 lines” viewpoint: either one is arguing that the assessment is improperly conducted, in which case you would need to conduct your own and provide that — or one is arguing that the assessed categorizations are not the correct ones to use, which is a separate useful debate that does not require reading all the messages.
I’ve learned to ‘ask first, write later’ when it comes to open source as well, unless I’m willing to fork or just keep the changes for myself. There’s no guarantee all contributions are welcome, so don’t sink the cost until you can be reasonably sure your code will get used.
He does not seem to understand that the favor is the maintainers accepting to merge his code.
Merging stuff blindly is just asking for trouble. Sometimes yes, it happens that somebody sends you code that does something you're not familiar with, like interacting with weird hardware you've never seen before. It's still the right thing to do to ask lots of questions about it, so that if that part of the code runs into a problem later you have some sort of idea of what to do about it.
'endless arguments about overall architecture'
That's the kernel, for you. Your modules don't exist alone
I understand the frustration, but complaining is only the first part. It's important to move on -- either to the desired outcome, an upstreaming, or elsewhere
I'm nowhere near talented enough to participate in this kind of work, I've only observed things that were interesting enough to come by.
One thing I've learned is that particular subsystems/areas are better than others. It's unfortunate, but sometimes it comes with the complexity -- eg: VFS and anything storage
A lot of it's surely academic, but I think they somewhat reasonably lean towards what's known/trusted and try to get it right before disrupting things
They have already taken a pile of submissions to do things that they swore Linux would never support on arm hardware.