Sure, I agree with you. But incremental problem solving is good. Think of it as a feature branch. It doesn’t seem like much when it’s first created, but it’s a place to work on the feature independent of the other branches. It is a space in which to work in semi-isolation to solve problems that you might not be able to solve directly in a production branch.
Work on this class of systems is happening now, outside of Fedora. I’d like to create a space for that work to happen where the intent is to upstream to Fedora things that are appropriate, rather than drifting further away.
That’s true today, but there is no guarantee that will be the case at any given point in time, which is the reason I’ve been given that the OpenRM module will not be built in Fedora’s kernel package.
I think the kernel maintainers are being perfectly reasonable to reject the out-of-tree module on the grounds that it could create conditions that would prevent upgrading to a new release series. But the need for a stable kernel is a natural consequence of that position.
I agree that Fedora should give significantly more regular maintenance work to the automation tools we use today, but from my point of view that’s outside the scope of this thread.
It’s incomplete, but I don’t think that’s the same as “useless.” It supports and enables the user-space bits. It allows users to install and run software, even if Fedora can’t pre-install that software.
Supporting the software that user want to run is not useless.
No, we are not. As I said in the proposal, some of the work we need to do is engineering work (packaging and platforms), and some of the work we need to do is community building.
NVIDIA gets mentioned a lot here because there are specific engineering tasks needed to close a gap in hardware support across major vendors.
For other platforms, where we’ve gotten more active support or better aligned support from vendors, we have the luxury of doing community building and promotional work.
I’m working on it.
I don’t know if I’ve phrased something badly, but that’s really specifically what I want to do. My goal is always to tell users how to participate, and give them entry points to do so.
Use of the updates-archive is not an alternative to a stable kernel. When there are hardware support regressions, or when there are interface changes that affect third-party kernel modules, the only option within Fedora is to stop updating the kernel.
A stable kernel package would continue to deliver security patches and serious bug fixes to users who can’t rebase to a new kernel series because of regressions or software support.
I think I agree with you on the facts, throughout your reply and on this point specifically. I just don’t come to all of the same conclusions.
RHEL is a product. Red Hat determines the intended use cases to fit the markets they want to participate in. They develop the product to support those use cases.
Fedora is not a product. The software we provide is unsupported, which is to say that we are not accountable to users. If the thing we build the publish works, they may use it, and if it doesn’t work, they can maybe participate and try to fix it or they can use something else. But there’s no mechanism for them to hold us accountable otherwise. Unlike Red Hat’s model, in which they are offering continued maintenance of components independent of upstream, Fedora does significantly less in-distro development, and is mostly doing distribution.
We might agree that Red Hat isn’t allocating developers to do significant development of the Fedora kernel, but I don’t think it’s reasonable to expect them to do that, nor do I think that a rolling kernel is structured to enable them to do that.
The purpose of a stable release system is that it allows groups to collaborate asynchronously. It allows the developers of a product to publish a release series to get a feature set in to the hands of interested users. The groups of users for whom that series works can upgrade immediately, and the groups for whom it doesn’t work can work on porting and bug fixing until it does. The rolling kernel timelines don’t overlap enough for that to be realistic. Regressions and porting cannot reasonably be addressed within the overlap. Users would suffer regressions, even if more developers were actively working on bug reports against the Fedora kernel. In other words, even if developers were addressing bug reports, we would need more overlap in maintenance windows AND we’d need a mechanism by which users could upgrade from one kernel release to the next on their own schedule, rather than shipping one rolling kernel package.
…which is exactly why a stable kernel that spans a release would benefit many users. I’m actually quite surprised to see anyone argue simultaneously that there are not enough developer resources assigned to the rolling kernel release and that the stable kernel isn’t useful or desirable. Those seem like contradictory points of view, to me. The latter is the solution to the former.