This has a reason, the Atomic Desktops are still not a part of the “official editions”.
(See description of the “Atomic Desktop” section on fedoraproject-org)
Atomic Desktops
These editions are supported but not yet a part of the official Fedora editions.
That is the reason, why they are a bit behind, wile releasing new versions/updates.
A future goal is to be able to release/update the Atomic desktops simultaneously with the other versions. It seems that the right process for this is still missing, and the appropriate infrastructure isn’t quite ready yet.
Uups .. non-immutable distro ! I focused on immutable, true.
So you are referring to the upstream project (gnome) with being “more timely”, right?
I think this is the matter, that we are not have a rolling release as you mentioned, like to have. While having release circles we are not able to be so much up to date.
I guess for this case the Rawhide version would be the more appropriate solution for your wish ?!
In any case, I consider the question of the update of the packages more important. I know it is a thorny topic, as regards the free work of many people. And I’m grateful to them. I just try to say that there are packages that are often updated late, some that have not been updated since last year and that, when you move on to a new version of OS, the previous one remains behind updates (despite having to be supported for 13 months). It would be nice if there were tools that would allow to automate these processes and lightened the work of the manteiner.
However, a rolling release would solve part of these problems.
@ilikelinux@steppybug
I am not referring to the release of Gnome updates, but Fedora.
Not even Rawhide would satisfy the criteria I place, as it does not have a testing phase, essential to keep a system safe. If I can make a parallelism, Manjaro is a good example (it is rare to find packages that are behind with updates).
To be precise, the Manjaro release cycle is this: as soon as a new version of the package is released upstream, this immediately enters the unstable branch; within 1-3 days enters the branch testing; in 1-2 weeks it enters the branch stable.
In Fedora the situation is very variable: there are packages that enter the branch stable before Manjaro and there are packages that enter the stable release even after more than a month their release upstream.
So, if I understand you correctly you mean being more “bleeding edge”? Updating upstream projects closer to the same time as Upstream?
If yes, this also would not work with our release circle strategy. We do not upgrade a old stable fedora version if there are dependencies not working on it. This avoids breaking working versions.
I don’t think the problem is that. I’ll give you an example: why can’t GStreamer be updated to version 1.24.12 (starting from version 1.24.11)? I understand that it is not led to version 1.26.0, but why not to 1.24.12? There are many of these examples. And the problem of semi-abandoned packages remains.
My answer would be that there are interest changing and missing manpower to take over projects before they get orphaned. Maybe a more present announcing strategy would help to avoid to get to much abandoned packages.
As we are a opensource project, anyone can participate to make pull request to the fedora packages or commenting on the source code of them. Or even better, sponsoring developers, especially if they are not working full time on such projects.
I see that we can discuss more and longer about that. I just propose to to create a own new topic for that and move the discussion we made her to this new topic. So the “what brought you to fedora?” topic is cleaner and better to read.
How about naming it: How to get closer to upstream versions for official fedora packages?
I think there are also developers and packagers which could give more input about that.
It’s just not worth it in terms of time investment.
A maintainer would need to spend time packaging it, then it would need to be deployed for testing, possible regressions or bug reports would have to be checked and adressed, as well as vulnerabilities, and finally it would have to be definitely deployed.
In the case of something like gstreamer there are also countless of plugins and 3rd party frameworks depending on specific Gstreamer versions. Who is going to check and update them all? And then again when version 1.24.13 is backported?
At the same time there is a new stable F42 release that you can easily upgrade to, and it will contain not only gstreamer 1.26.0 but updates to all the other packages on the system.
Fedora is only a 6 month release cycle, it’s quite close to a rolling a release while being much more stable than one.
You had a great idea. I take some time to understand how to set up the discussion, in order to make it interesting and constructive.
As for the participation in the maintenance of the packages, I fear that it is not within everyone’s reach. Otherwise many users of Fedora would contribute without problems. In the documentation there is a lot of stuff and not everything is easy to understand.
Ok, explained like this it is clearer.
I just want to make it clear that I don’t think the problem is the maintainers (absolutely! Without them, nothing of what we are talking about would exist. And to them I say thank you every day.), but the system itself, which requires a lot of work.
Having said that, I close the discussion on the topic.
That is a good point – the release cycle is short enough that you’re not gazing at the latest kernel from two years away, like some distros I can think of. Since Fedora upgrades gracefully (and I remember the bad old days when every version upgrade was a full reinstall) and updates happen between, it really isn’t that different from rolling. (I’ve found rolling more stable, maybe because bugs get fixed sooner, but not a big difference. Fact is in the KDE ecosystem I rarely see bugs either way, because they usually get fixed before I can encounter 'em.)
O moved the conversation out of the what brought me to fedora. This way the conversation there keeps clean and focus on the topic. I also add a block quote to the first post to see what was the initiation of the conversion was.
We thought Fedora was first!