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.
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.
He's always been a little like this. Fits the hot blooded Spaniards steriotype quite well. He'll get pissed off about something, fly off the handle and then calm down eventually. In the meantime he may churn out some very cool stuff because he actually is very technically talented.
> 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.
> 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.
I can only guess the author isn't thinking systematically about this issue. They know their own motivations, their own coding skills, their own reasons for doing everything, and they know they are submitting well intentioned, beautiful, useful code.
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.
I am a little confused by his expectations. He describes it as a "what should've been a 30 minute fix patch" and "a 1700-line patchset that implements 3 kernel modules".
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.
I think "should have been" implies here that it wasn't a 30-minute-fix patch — with possible insult intended toward a highly-coupled part of the kernel architecture that made the fix require touch-points than it should have.
> because the other side doesn't bother to actually stop and think about the problem we're trying to solve and why.
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.
I'm getting tired of hearing people complain about the governance of GPL projects. If you don't want to cut through the red tape of a globally-sponsored, stable product, then don't use it. The code is GPL, nobody will arrest you for forking it.
> 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.
I agree entirely. If you try to get a patch to be accepted, be prepared to explain exactly what it does bit by bit to people whose entire job it is to make sure that the kernel quality does not degrade.
> The code is GPL, nobody will arrest you for forking it.
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.
Sorry, but part of being a good engineer is being able to explain why your work is critical (or isn’t, be honest) and how it works in as reasonably simple terms as possible.
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.
The main power of a maintainer is to reject code. Once it's merged, it becomes the maintainer's problem. So if they don't understand what's it's supposed to accomplish, or how exactly it works, a good maintainer should reject the 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.
The usual cycle is: two kernel maintainers have an endless argument about overall architecture, and one or another of them blocks any submission, so nothing could be done until this endless argument is resolved by them.
My understanding is that he is a very talented and valuable programmer and contributor, and it's a loss for everyone if he has to waste hours and days on arguing. I'm not saying I have the solution or anything, just saying I do think he has a point.
Ah, another feather in my cap. I keep saying that Linux's "drivers-included" model won't scale long-term. I'm just going to sit back and sip some iced tea, soon you all will come around to my way of thinking, and Linus (or someone) will announce an amazing new initiative to move drivers out of the kernel tree.
[+] [-] sweden|3 years ago|reply
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.
[+] [-] Fatnino|3 years ago|reply
[+] [-] jbirer|3 years ago|reply
[+] [-] mikelward|3 years ago|reply
[+] [-] schainks|3 years ago|reply
> 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.
[+] [-] googlryas|3 years ago|reply
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.
[+] [-] dottedmag|3 years ago|reply
[deleted]
[+] [-] thethirdone|3 years ago|reply
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.
[+] [-] derefr|3 years ago|reply
[+] [-] dottedmag|3 years ago|reply
[deleted]
[+] [-] throwawayffffas|3 years ago|reply
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.
[+] [-] dottedmag|3 years ago|reply
[deleted]
[+] [-] smoldesu|3 years ago|reply
> 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.
[+] [-] j-krieger|3 years ago|reply
If you can't, quit.
[+] [-] daxelrod|3 years ago|reply
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.
[+] [-] nells|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] dottedmag|3 years ago|reply
[+] [-] anikom15|3 years ago|reply
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.
[+] [-] throwawayffffas|3 years ago|reply
He does not seem to understand that the favor is the maintainers accepting to merge his code.
[+] [-] dottedmag|3 years ago|reply
[deleted]
[+] [-] dale_glass|3 years ago|reply
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.
[+] [-] dottedmag|3 years ago|reply
[deleted]
[+] [-] bravetraveler|3 years ago|reply
'endless arguments about overall architecture'
That's the kernel, for you. Your modules don't exist alone
[+] [-] dottedmag|3 years ago|reply
[+] [-] im3w1l|3 years ago|reply
[+] [-] StillBored|3 years ago|reply
They have already taken a pile of submissions to do things that they swore Linux would never support on arm hardware.
[+] [-] phendrenad2|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] phendrenad2|3 years ago|reply