Imagine you wrote a WYSIWYG text editor, like Libre Office Writer. You have all sorts of functionality and an overall architecture which makes it sane to upkeep the project & have things work well together. Then someone else makes a custom font, but kind of does it their own way and with a different approach making it a one off from the way the rest of the fonts all work and are used in the program maybe using a custom font file format parser and different UI element even though you know it could have just used the normal, already maintained and planned out code paths.
You can of course merge anything with the right license if you so like, like that one off font code into your editor, but if it doesn't fit well into the overall project or meet the general quality standards of it then it's not practical to and can actually be worse than not including it. Upstreaming is about submitting something the maintainer can reasonably accept and maintain, not just about whether working code is available. GPL licensed code provides the latter, it's still up to someone (either the original company or some other interested person) to make it fit right first.
"Quality" is maybe overloaded. Upstream requires the code to meet their sense of taste, and some of that is about quality, and some of that is about undocumented design concepts. It's not hard to meet the quality bar. Meeting the design requirements is extremely hard.
Ofcourse they can. But which particular person will do it ?
The "upstream" people deal with their own drivers, subsystems or tasks which takes up their time - but if someone feels they want to take on this too, they'll do it (normally that doesn't happen - it's up to the original authors to take responsibility)
Linux tries to avoid special cases. That means that when someone shows up with a new driver that's either not something that fits into an existing category, or which sort of (but doesn't entirely) overlap with an existing driver, there's an extended set of design discussions about how to make this new driver fit into existing infrastructure in a way that's consistent with what's there and which also allows new things to exist.
That sounds great from a design perspective, but it can also lead to cases where people are attempting to design for utter unknowns - potential futures that may or may not exist, theoretical understandings of how hardware works, that kind of thing. It frequently prevents new drivers being merged without significant modification, and sometimes it results in a need to entirely rearchitect the relevant part of the kernel before the driver can even be considered (and also now you need to split that driver into three parts). Upstreaming is hard.
Imagine you wrote a WYSIWYG text editor, like Libre Office Writer. You have all sorts of functionality and an overall architecture which makes it sane to upkeep the project & have things work well together. Then someone else makes a custom font, but kind of does it their own way and with a different approach making it a one off from the way the rest of the fonts all work and are used in the program maybe using a custom font file format parser and different UI element even though you know it could have just used the normal, already maintained and planned out code paths.
You can of course merge anything with the right license if you so like, like that one off font code into your editor, but if it doesn't fit well into the overall project or meet the general quality standards of it then it's not practical to and can actually be worse than not including it. Upstreaming is about submitting something the maintainer can reasonably accept and maintain, not just about whether working code is available. GPL licensed code provides the latter, it's still up to someone (either the original company or some other interested person) to make it fit right first.
Upstream requires a level of quality most developers cannot meet.
"Quality" is maybe overloaded. Upstream requires the code to meet their sense of taste, and some of that is about quality, and some of that is about undocumented design concepts. It's not hard to meet the quality bar. Meeting the design requirements is extremely hard.
Perhaps "maintainability" is a more suitable term?
Ofcourse they can. But which particular person will do it ?
The "upstream" people deal with their own drivers, subsystems or tasks which takes up their time - but if someone feels they want to take on this too, they'll do it (normally that doesn't happen - it's up to the original authors to take responsibility)
Linux tries to avoid special cases. That means that when someone shows up with a new driver that's either not something that fits into an existing category, or which sort of (but doesn't entirely) overlap with an existing driver, there's an extended set of design discussions about how to make this new driver fit into existing infrastructure in a way that's consistent with what's there and which also allows new things to exist.
That sounds great from a design perspective, but it can also lead to cases where people are attempting to design for utter unknowns - potential futures that may or may not exist, theoretical understandings of how hardware works, that kind of thing. It frequently prevents new drivers being merged without significant modification, and sometimes it results in a need to entirely rearchitect the relevant part of the kernel before the driver can even be considered (and also now you need to split that driver into three parts). Upstreaming is hard.
I get that. But it's a platform that is so similar to existing Linux on ARM offerings.
All the subsystems to run a laptop should already be there, no?
ARM isn't consistent in the way that the x86 platform is. Each vendor's SoC usually requires specific support.
1 reply →