Is anyone else interested in working on a rolling release spin of Fedora?
I've never put together a spin before, so I'm not sure how much help I can give aside from testing. What I'm trying to help achieve is a Fedora spin that is basically the same as the Rawhide, except uses stable (~6 month old) packages.
This is my motivation: I'd love to never have to worry about distribution upgrades, big modifications to my MBR/EFR, changing repo URLs, and all the other junk that goes along with upgrading the distribution from x to x+1. Without that *stuff* the OS would be much easier to use over time, and certainly something I would have no problems recommending to a new Linux user. As it stands now, I think the distro upgrade process of Linux distros is an unnecessary difficulty for most desktop users, when using 'yum' for continuously updating the packages would work just as well.
On Thu, 9 Jan 2014 21:44:17 -0500 Gavin Engel gavin@engel.com wrote:
Is anyone else interested in working on a rolling release spin of Fedora?
I'm not sure how this could work as a spin, unless you used rawhide only I guess, but you don't want to do this that it sounds like?
I've never put together a spin before, so I'm not sure how much help I can give aside from testing. What I'm trying to help achieve is a Fedora spin that is basically the same as the Rawhide, except uses stable (~6 month old) packages.
You would need the maintainers to maintain those, the infrastructure to build and push them, the release engineering resources, qa folks, etc.
6 month old packages aren't inately more stable... it depends on how they are maintained.
This is my motivation: I'd love to never have to worry about distribution upgrades, big modifications to my MBR/EFR, changing repo URLs, and all the other junk that goes along with upgrading the distribution from x to x+1. Without that *stuff* the OS would be much easier to use over time, and certainly something I would have no problems recommending to a new Linux user. As it stands now, I think the distro upgrade process of Linux distros is an unnecessary difficulty for most desktop users, when using 'yum' for continuously updating the packages would work just as well.
My take:
rolling release means you have to do large/radical updates as the maintainer(s) decide, while releases means you can decide when to do those yourself on your own schedule (within a 6 month window).
kevin
Hello Kevin, thank you for responding.
Maybe "Rolling Release" means something different to me than everyone else. To me, it doesn't necessarily mean cutting edge packages, only that there is no OS version number (*like version 19, 20, etc*). So, my thought to make things as easy to maintain (*for spin maintainers*) as possible is to simply serve 6 month old packages as long as they haven't had a security update.
I don't know what it would take though. Would this stable RR need hosting for all its own packages, or would it be it simply be enough to have a URL to alias to the current version of Fedora? That way, this RR wouldn't need any extra engineers or qa folks, it would simply piggy-back on the work of the main Fedora folks. For example, instead of including a Fedora version number in the repository URL:
http://download.fedoraproject.org/pub/fedora/linux/updates/*20*
something like this (I'm using a made up word 'suede', which is similar to 'rawhide' in English ):
http://download.fedoraproject.org/pub/fedora/linux/updates/*suede*
Now, that second link with suede could easily just point to the current version (*and the existing mirrors*) of Fedora, which is now 20. That way there would be no need for the end user (*for instance, my mother*) to bother with FedUp, or other distribution upgrades. The only thing needed would be to run 'yum update' every so often, perhaps even by cron. The contents of /etc/issue would state 'Fedora Suede", and the GRUB screen would state 'Fedora Suede'. (*Without Linux kernel # in GRUB, I'd imagine. That way there is less to keep updated*).
Do that even make sense? I must be missing something here, as it seems too simplistic.
On Fri, Jan 10, 2014 at 3:51 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 9 Jan 2014 21:44:17 -0500 Gavin Engel gavin@engel.com wrote:
Is anyone else interested in working on a rolling release spin of Fedora?
I'm not sure how this could work as a spin, unless you used rawhide only I guess, but you don't want to do this that it sounds like?
I've never put together a spin before, so I'm not sure how much help I can give aside from testing. What I'm trying to help achieve is a Fedora spin that is basically the same as the Rawhide, except uses stable (~6 month old) packages.
You would need the maintainers to maintain those, the infrastructure to build and push them, the release engineering resources, qa folks, etc.
6 month old packages aren't inately more stable... it depends on how they are maintained.
This is my motivation: I'd love to never have to worry about distribution upgrades, big modifications to my MBR/EFR, changing repo URLs, and all the other junk that goes along with upgrading the distribution from x to x+1. Without that *stuff* the OS would be much easier to use over time, and certainly something I would have no problems recommending to a new Linux user. As it stands now, I think the distro upgrade process of Linux distros is an unnecessary difficulty for most desktop users, when using 'yum' for continuously updating the packages would work just as well.
My take:
rolling release means you have to do large/radical updates as the maintainer(s) decide, while releases means you can decide when to do those yourself on your own schedule (within a 6 month window).
kevin
spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On Sat, 11 Jan 2014 18:50:49 -0500 Gavin Engel gavin@engel.com wrote:
Hello Kevin, thank you for responding.
No problem, although I fear I don't have time to do a full reply here. ;)
Maybe "Rolling Release" means something different to me than everyone else. To me, it doesn't necessarily mean cutting edge packages, only that there is no OS version number (*like version 19, 20, etc*). So, my thought to make things as easy to maintain (*for spin maintainers*) as possible is to simply serve 6 month old packages as long as they haven't had a security update.
The problem with that is that no package is an island. If you build a package against a collection of other packages, it may well need those versions to function. So, if you update one package that in turn is used by another set you have to rebuild a lot of things and update them in one big mass.
...snip...
Do that even make sense? I must be missing something here, as it seems too simplistic.
No, it will not work. You can't mix random piles of packages that were not built together up and have any hope of it working. ;)
Perhaps this will help, it's a blog post I made the last time rolling releases came up on the devel list. (you might also look at the archives for the devel list for around that time too.
http://www.scrye.com/wordpress/nirik/2013/01/04/on-rolling-releases/
HTH
kevin
Thank you Kevin. I've read your blog post. I'll probably add a comment on that with a follow up.
On Tue, Jan 14, 2014 at 4:27 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 11 Jan 2014 18:50:49 -0500 Gavin Engel gavin@engel.com wrote:
Hello Kevin, thank you for responding.
No problem, although I fear I don't have time to do a full reply here. ;)
Maybe "Rolling Release" means something different to me than everyone else. To me, it doesn't necessarily mean cutting edge packages, only that there is no OS version number (*like version 19, 20, etc*). So, my thought to make things as easy to maintain (*for spin maintainers*) as possible is to simply serve 6 month old packages as long as they haven't had a security update.
The problem with that is that no package is an island. If you build a package against a collection of other packages, it may well need those versions to function. So, if you update one package that in turn is used by another set you have to rebuild a lot of things and update them in one big mass.
...snip...
Do that even make sense? I must be missing something here, as it seems too simplistic.
No, it will not work. You can't mix random piles of packages that were not built together up and have any hope of it working. ;)
Perhaps this will help, it's a blog post I made the last time rolling releases came up on the devel list. (you might also look at the archives for the devel list for around that time too.
http://www.scrye.com/wordpress/nirik/2013/01/04/on-rolling-releases/
HTH
kevin
spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On Tue, Jan 14, 2014 at 04:46:28PM -0500, Gavin Engel wrote:
Thank you Kevin. I've read your blog post. I'll probably add a comment on that with a follow up.
If you're still interested, I think the most helpful thing to do would be to contribute to efforts related to the last thing in Kevin's blog post: making rawhide a little less risky.
Hi Matthew. Actually I just noticed that his comment section is closed on that blog post, so I'll follow up to you both here.
I think rawhide is a bit too "raw", and I think stable branches are too confining. Would it be feasible to have a package tool that allows a user to choose how each package version should be auto-updated: major or minor. I understand how auto upgrading from 1.0.1 to 2.0.1 can cause a lot of confusion, so I suppose packages should be defaulted to "minor" updates each time yum update is run. In other words, automatically updating from 1.0 to 1.x. Then again, I'm comfortable setting most of my packages (perhaps not libraries) to auto update "major", meaning version 1.x to 2.x. I see no reason why the choice couldn't be left to the end user. Maybe all that is needed is a bash script that runs yum update on a rawhide installation, and accepts major version updates if the package is set to allow "major" version updates. Would that make any sense?
I would like to help the Fedora team where I can. My second question here is, how would I help make rawhide less risky? Do I just send bug reports to the rawhide mailing list?
On Tue, Jan 14, 2014 at 4:49 PM, Matthew Miller mattdm@fedoraproject.orgwrote:
On Tue, Jan 14, 2014 at 04:46:28PM -0500, Gavin Engel wrote:
Thank you Kevin. I've read your blog post. I'll probably add a comment
on
that with a follow up.
If you're still interested, I think the most helpful thing to do would be to contribute to efforts related to the last thing in Kevin's blog post: making rawhide a little less risky.
-- Matthew Miller -- Fedora Project -- mattdm@fedoraproject.org _______________________________________________ spins mailing list spins@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/spins
On Tue, Jan 14, 2014 at 17:13:41 -0500, Gavin Engel gavin@engel.com wrote:
I understand how auto upgrading from 1.0.1 to 2.0.1 can cause a lot of confusion, so I suppose packages should be defaulted to "minor" updates each time yum update is run. In other words, automatically updating from 1.0 to 1.x. Then again, I'm comfortable setting most of my packages (perhaps not libraries) to auto update "major", meaning version 1.x to 2.x. I see no reason why the choice couldn't be left to the end user. Maybe all that is needed is a bash script that runs yum update on a rawhide installation, and accepts major version updates if the package is set to allow "major" version updates. Would that make any sense?
That won't work. For leaf packages, sometimes people will make newer releases available various places. Things get much more difficult with packages that other things depend on.
If there are just a few packages you really want up to date, you might trying doing your own builds of those. For example you might run mostly Fedora 20, but rebuild a few Rawhide (Fedora 21) source rpms for packages you want more up to date than are in Fedora 20. For a lot of packages this will work fairly easily most of the time.
I would like to help the Fedora team where I can. My second question here is, how would I help make rawhide less risky? Do I just send bug reports to the rawhide mailing list?
The biggest thing would be to run rawhide on some machine you use regularly and provode feedback. Bug reports should be filed against bugzilla. Though sometimes you might ask questions on the mailing list to help fill out the bug report.
-
Bruno Wolff III -
Gavin Engel -
Kevin Fenzi -
Matthew Miller