[MfA]

How can it be that multiple major distributions maintain and update patch sets for projects for years, without real alternatives being in the kernel, yet they are not considered worthy of being included?

Majorly :

DM-RAID45 ... MD-RAID is a poor alternative, someone is attempting to "integrate" the MD-RAID code inside DM-RAID45 to seduce maintainers to include it but frankly the original DM-RAID45 code is superior and cleaner. They say it should be integrated with MD-RAID because it's time tested, when DM-RAID45 has been in production use for years by Redhat (and multiple other distributions among which Ubuntu and Suse include it in their own kernels).

AUFS2 ... the VFS maintainer refuses to allow it in mainline because it exports VFS internals, while he thinks it should be an integral part of VFS (personally I think putting it in mainline and using it to test VFS functionality as it's put in would be the best way to do that, but who am I). As an alternative he proposes union mounts, which only covers a small part of the use cases of current union filesystems (so union mounts will likely be completely fucking ignored, with distributions plugging away keeping it up to date on their own). Proposes as in "they might get written" even, they don't exist.

When 10's of % of linux users use these things in production for years it should be in mainline ... fucking tossers.

Now this wouldn't be so bad, if my distribution of choice (Debian) didn't have a raging hard on for the political views of mainline kernel maintainers ... so they refuse to support these in Debian too ... ugh, I guess I'll have to switch to Ubuntu ... ICK.

[flynn]

Switch to FreeBSD

[stevem]

- and live your life on the ports dependency treadmill instead...

[MfA]

I really want to use AUFS2 though, UnionFS is just not quite on the same level.

Also I got really used to dselect for package management ... so Ubuntu it is ... again, ICK.

[Npl]

Yeah, stupid "free" politics.

My pet peeve is the cdrtools dispute. The original has parts under CDDL, a FSF approved license, but that wasnt enough since its not "recommended" (whatever that means) to mix GPL and CDDL apps. The result was that debian forked cdrtools and this fork is buggy and way behind the official branch.
Its not possible to easily choose the official branch because the fork uses the same filenames and automatic updates could overwrite them.

So for some esoteric reasons you end up with buggy software which masks itself as the original. Way to piss off users and disrespect the original authors which now get the buggy branch associated with them.

[MfA]

Originally Posted by Npl

Yeah, stupid "free" politics.

License issues are a different matter ... and clearly the maintainer is a bit of a troll by trying to mix CDDL and GPL for no other reason than to cause problems.

The original has parts under CDDL, a FSF approved license

I guess you mean OSI? Because the FSF and the cdrtools author have a bit of a disagreement as well (which for some curious reason is not mentioned on that page).

[Npl]

Originally Posted by MfA

License issues are a different matter ... and clearly the maintainer is a bit of a troll by trying to mix CDDL and GPL for no other reason than to cause problems.

its not mixed AFAIK, it changed from GPL to CDDL.
The issue is not about using CDDL`ed code or libraries, cdrtools are applications which dont fall into the source/linking restrictions. The issue is the decision of eg. Ubuntu to not include this (atleast as option) while providing repositories with nonfree or even legally questionable software (decss libraries).

If there are trolls then its those that assume only FSF licenses are free open source and try to kill/suppress everything else (weird interpretation of the "fair competition" only FSF-licenses allegedly guarantee).

Originally Posted by MfA

I guess you mean OSI? Because the FSF and the cdrtools author have a bit of a disagreement as well (which for some curious reason is not mentioned on that page).

Yep OSI, my bad.

[MfA]

Just my impression ...

The author ran into a rabid GPL maintainer who wronged him somehow, so as revenge he started licensing his software as CDDL ... which would cause a lot of controversy since FSF doesn't really like it, but since it's still copyleft authors are unlikely to make a huge legal deal about it (Debian is a stickler for legality even if authors don't sue of course). Since despite being a bit of a troll he is a good programmer and his software is useful he has managed to badger most of the people who's libraries he uses to make them more compatible with CDDL over the years just to shut up the users whining for it ... which brings us to the present day.

[tuna]

Originally Posted by MfA

How can it be that multiple major distributions maintain and update patch sets for projects for years, without real alternatives being in the kernel, yet they are not considered worthy of being included?

Majorly :

DM-RAID45 ... MD-RAID is a poor alternative, someone is attempting to "integrate" the MD-RAID code inside DM-RAID45 to seduce maintainers to include it but frankly the original DM-RAID45 code is superior and cleaner. They say it should be integrated with MD-RAID because it's time tested, when DM-RAID45 has been in production use for years by Redhat (and multiple other distributions among which Ubuntu and Suse include it in their own kernels).

AUFS2 ... the VFS maintainer refuses to allow it in mainline because it exports VFS internals, while he thinks it should be an integral part of VFS (personally I think putting it in mainline and using it to test VFS functionality as it's put in would be the best way to do that, but who am I). As an alternative he proposes union mounts, which only covers a small part of the use cases of current union filesystems (so union mounts will likely be completely fucking ignored, with distributions plugging away keeping it up to date on their own). Proposes as in "they might get written" even, they don't exist.

When 10's of % of linux users use these things in production for years it should be in mainline ... fucking tossers.

Now this wouldn't be so bad, if my distribution of choice (Debian) didn't have a raging hard on for the political views of mainline kernel maintainers ... so they refuse to support these in Debian too ... ugh, I guess I'll have to switch to Ubuntu ... ICK.

I do not think it is the "politics" you are mad at, rather the fact that the current maintainers of various Linux sub-systems have different technical opinions than other developers. This is quite common in software development projects.

[MfA]

When they are unable to set their opinions aside and instead propose pie in the sky alternatives, which they aren't willing to code themselves, for production ready code with maintainers seeking to mainline it simply because they find the architecture aesthetically displeasing ... then it becomes politics.

They can impose their will on the strength of their position rather than their argument.

[tuna]

Originally Posted by MfA

They can impose their will on the strength of their position rather than their argument.

That is the essence of management and authority. You can always ask Torvalds to merge your feature, but it is more likely he trusts his chosen maintainers than other people. Which seems to be the case everywhere else as well.