Originally posted by Mario Junior
View Post
Announcement
Collapse
No announcement yet.
Paragon's NTFS Driver For The Linux Kernel Spun Up A 27th Time
Collapse
X
-
- Likes 1
-
Originally posted by evasb View Post
Because their NTFS driver doesn't have any MS code, it's a clean room implementation.
They need to just do a pull request already.
Leave a comment:
-
Originally posted by evasb View Post
I apologize for putting "unsaid things" in quotes, but this is the Maintainer's point.
He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.
I don't feel any fun on this.
On the other hand, it's the patch creator who (AFAICT from that exchange I read) never responded to the advice and guidelines, and my impression on that was not that he was a first time contributor who simply became overwhelmed with the responsibility, but rather a guy who was too lazy to refactor the patch in a proper and maintainable way, again, as per the advice and guidelines provided. Now, I do realize the need for the functionality (I myself have an ASUS X470 mobo that currently utilizes an out-of-tree WMI driver for reading sensors) but that doesn't mean we should be turning the kernel into another X11 spaghetti festival. As a previous commenter said, open source does not mean low standards (or hacky solutions, if I may add).
As a final note, indeed, the Linux kernel today is more an enterprise product and less a CS student's hobby project. This has both advantages and disadvantages, but I really do not consider not accepting hacky patches that do not conform to the kernel standards as a disadvantage. And if the maintainer is simply being a moron and the patch is in fact good (disclaimer: I haven't seen it), then why doesn't the author simply send a mail to Linus and ask him to intervene? I mean, we're still talking about an open source kernel here.
- Likes 1
Leave a comment:
-
Originally posted by evasb View Post
I apologize for putting "unsaid things" in quotes, but this is the Maintainer's point.
He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.
I don't feel any fun on this.
Leave a comment:
-
Originally posted by birdie View PostI'm talking about how difficult is to get your code merged despite the proclamations that it's open source and everyone is welcome to contribute. Not only you're not welcome, you have to work your buttocks off to be accepted. It's the 27th revision of the NTFS code - how crazy it is?
Never mind, I'm an old geezer and I'm talking BS. Linux is perfect, it perfectly supports everything and it has a ton of perfect software for it.
- Likes 1
Leave a comment:
-
Originally posted by Nocifer View Post...
He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.
I don't feel any fun on this.
- Likes 2
Leave a comment:
-
Originally posted by evasb View Post
WTF, the guy tried to upstream the patch, got rejected ("don't want to use ifdefs"), the guy asked for suggestions and the maintainer's response was "NO IDEA".
No wonder Bernhard Seibold doesn't want to work on it anymore
Originally posted by MaintainerNo, this makes the driver unmaintainable. There should be a separate driver which only makes WMI/ACPI accesses for everything.
Guenter
Originally posted by MaintainerNo idea, quite frankly. Sprinkling the driver with ifdefs and conditional code for sure isn't the solution. You might consider dropping the ifdefs and use dmi detection instead, possibly with a module parameter to bypass the dmi detection. I'd rather have no ifdefs and miss some platforms where this is untested.
You could try by splitting the single patch into several patches, with one or more preparatory patches, and maybe write accessor functions to avoid the runtime conditonals. Oh, and don't use C++ comments.
Guenter
It's always fun taking things out of context and even putting unsaid things in quotes ("don't want to use ifdefs") in order to make reality fit with your point of view, eh?
In other news, birdie is back from his long-term vacation and it's like his posts have been perfectly preserved in time. Same old, same old.
- Likes 4
Leave a comment:
-
Also improving on someone else coded to get it merged isn't unheard of in open source development and I don't know why people are giving it the negative connotation that they are (especially if the guys don't provide an alternative).
Code style is obviously something that the contributor should fix though
- Likes 3
Leave a comment:
Leave a comment: