Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, 05 Nov 2012 13:53:37 +0100, Ralf Corsepius wrote: That's called CentOS, Nope ... CentOS/RHEL is a different end of extremes. 7 years+ life-time, no API changes, etc. What is lacking is a middle ground between Fedora and CentOS. Something with a life-time of ~2 years, with API increments etc. I am not saying that you are completely wrong, because you are not, but I would remind you that this thread started (at least for me) with adamw admission that we are not managing well even 13-month-distro, so I am afraid we don't have a luxury to think about ~2 years one at all. Moreover, RHEL/CentOS is not a Debian/stable, i.e, it is not 100% frozen (no API changes is just for kernel and core libraries, IIRC), and there are (especially in desktop land) some rebases, so I found it for my wife's usecase pretty useful. Looking at her computer I see firefox-10.0.10-1.el6_3.i686.rpm and libreoffice-3.4.5.2-16.1.el6_3.i686 ... certainly not a bleeding edge, but not unusably old. On the top of that, the past is not an indicator of the future (and I DO NOT say anything about the future ... NDA, not talking for my employer, etc.) but new releases of RHEL usually come in some ~2-3 years you desired, so if you are willing to reinstall with every new RHEL/CentOS (or with version x.1, which is quite common), then that could be your desired system. Just saying, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
mike cloaked píše v Ne 04. 11. 2012 v 21:44 +: On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com wrote: This is a very valid argument. I understand this is a devel list, so we should stay on the technical level, but if we discuss such broad changes that affect the whole project, we should also take into account other aspects. Switching to rolling release would have a *huge* negative impact on marketing! It's releases what makes the fuzz and their announcements get beyond our current user base. We would have no release parties, no codenames. We would lose the product. I wonder what impact it would have on Fedora adoption by cloud providers. I think it's much more understandable not only for them, but also for their customers to take Fedora 17 than some monthly build. Does anyone have any reliable statistics about the number of users who feel that release parties and codenames are important to them? Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. Or fp.org monthly stats. You would lose reviews, that are usually published after releases, because I don't see any reviews of rolling release distributions by main magazines. Etc. BTW this is not just about current Fedora users. Marketing is mainly about potential users. There will no doubt be some people for whom the idea of running a particular codenamed release is important - but there will also be others for whom a high quality established linux distribution that is reliable and up to date irrespective of its codename is more important. Marketing feedback if it is possible to give the relative number of users in each camp would be helpful here? Gathering such statistics is likely difficult though. I personally don't like the whole idea of switching to rolling release. Although I see some pros, I see a lot of cons that would outweight the pros. I've come across a few rolling release distributions (Debian Testing, Arch Linux, Gentoo,...) and I don't think they work if you want to achieve some level of stability and predictability. Arch linux is stable and reliable and predictable - I use it every day - you need to ask users of the other distributions named whether users feel they are similarly stable and predictable or not for the most part. Well, as someone has already said here: stability and reliability are relative terms. I used Arch Linux for a while and I didn't find it stable and reliable on the level where I'd like to see Fedora. If you have to read release notes before every update to make sure you know what might break and how to fix it, then you're not using a system that would be appealing to a large number of user. And Fedora has always been aiming much broader audience than Gentoo or Arch. Does anyone have any relative user stats on the various distros? Do any web sites gather stats which might indicate hit rates coming from different distros? These data are difficult to get so in the end a clear goal for any distribution has to be agreed on and then executed - if Fedora wishes to go to rolling Rawhide but a bit more stable that at present and it is possible to do that - then developers must agree at least on some kind of overall vote maybe? In the end the users will guide whether the route taken is being adopted widespread among the community. You get some idea of users interested from feedback to the devel list, or via bodhi I guess? One other question that is hard to answer is whether a particular change in direction is achievable since it depends on developers adopting it and agreeing to work on it - inevitably some will not want to go to any new route - but will the new direction excite other developers to come on board that were not there before and make up any loss? The way I see it is that the two routes are a bit like asking if people like meat or fish for the main course at a meal - there will be a split opinion - and there are good points about both! Some people may be allergic to one or other though! Is there an objective list of pros and cons that can be judged without bias in favour of rolling release or periodic releases so that a logical weighing of the relative merits of both approaches can be considered? If that goes in favour of rolling release then can it be achieved with the tools available without too much effort? If new tools have to be built within the Fedora Framework is there enough effort and willingness to build them? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote: mike cloaked píše v Ne 04. 11. 2012 v 21:44 +: On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com wrote: This is a very valid argument. I understand this is a devel list, so we should stay on the technical level, but if we discuss such broad changes that affect the whole project, we should also take into account other aspects. Switching to rolling release would have a *huge* negative impact on marketing! It's releases what makes the fuzz and their announcements get beyond our current user base. We would have no release parties, no codenames. We would lose the product. I wonder what impact it would have on Fedora adoption by cloud providers. I think it's much more understandable not only for them, but also for their customers to take Fedora 17 than some monthly build. Does anyone have any reliable statistics about the number of users who feel that release parties and codenames are important to them? Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. That just means our marketing is virtually inexistant between two releases. A rolling release model would mean that our buzz would be lower than the peak values, but it would be constant. Depending on how you look at it, it could be a net win. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/05/2012 01:13 PM, Mathieu Bridon wrote: On Monday, November 05, 2012 06:56 PM, Jiri Eischmann wrote: mike cloaked píše v Ne 04. 11. 2012 v 21:44 +: Does anyone have any reliable statistics about the number of users who feel that release parties and codenames are important to them? Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. That just means our marketing is virtually inexistant between two releases. A rolling release model would mean that our buzz would be lower than the peak values, but it would be constant. It does not work this way :) The number of volunteers promoting Fedora is limited and their time is limited, do not expect them to promote Fedora 24 hours a day, 365 days a year, they will focus on important things, like the releases (but not only). Also, is the matter of saturation: the general public has its own priorities, if you barrage them with a constant flux of Fedora related news, they will quickly become bored: what? yet another feature in Fedora? just like the other gazillion they make public every other day? -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 5, 2012 at 10:56 AM, Jiri Eischmann eischm...@redhat.comwrote: Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. Or fp.org monthly stats. You would lose reviews, that are usually published after releases, because I don't see any reviews of rolling release distributions by main magazines. Etc. Here is one: http://www.linuxuser.co.uk/features/under-the-hood-with-arch-and-gentoo From a few weeks ago! BTW this is not just about current Fedora users. Marketing is mainly about potential users. Sure - Well, as someone has already said here: stability and reliability are relative terms. I used Arch Linux for a while and I didn't find it stable and reliable on the level where I'd like to see Fedora. If you have to read release notes before every update to make sure you know what might break and how to fix it, then you're not using a system that would be appealing to a large number of user. And Fedora has always been aiming much broader audience than Gentoo or Arch. Generally speaking for arch linux you don't get release notes for packages as such - and for the most part a regular update merely requires the following command: #pacman -Syu then accept or reject running the set of updates that is offered. Not a big deal - now and again there is an announcement on arch-announce (also on their main web page) which says run the following command (or two!) before the next update or similar - hardly a major hassle every few months. It's true that for my Fedora boxes I just have to run: #yum -y update or #yum update and then accept or reject the set of updates offered - much the same really. however for F16 which is current I don't have the latest KDE, or the latest systemd, or the latest libreoffice etc - which I do on my arch boxes. For any user that does not mind having KDE work OK but not with the latest round of bug fixes and new features it is fine. Similar with the other packages. Chrome is not offered as mainline by either distro but on Fedora google has a yum repo - so I run the latest chrome just fine on F16 - and in arch there is the latest via the AUR system so I run the latest chrome there too. But I won't have to run any re-install on the arch boxes whereas in order to keep my F16 boxes supported I will have to re-install around the end of the year. I know there are constant reminders from people who say they have never re-installed and just preupgrade but my own experience with that around the F9 timeframe was really poor - and I ended up doing a sequence of manual steps along with various yum upgrades/updates and kept a box going through two releases before deciding that a clean install was about the only sensible way forward at that time - maybe it is really quite trouble free updating from one release to another these days - so maybe my F16 boxes could be upgraded nice and easy to F17 and F18 with only a few commands and a bit of a wait - but I am not convinced it is worth the risk as one of them is a server! So it is horses for courses - I have two courses and a number of horses and so far none of the horses have died! -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/05/2012 01:11 AM, Matěj Cepl wrote: On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote: and one stable release ( valid for 2 maybe 3 years ) for those in the community that want something they dont constantly having to upgrade to and can deploy on their servers. ( ofcourse to have a stable release we first and foremost would need maintainers willing to maintain the distribution for that time, epel could maybe be simply dropped for that ). That's called CentOS, Nope ... CentOS/RHEL is a different end of extremes. 7 years+ life-time, no API changes, etc. What is lacking is a middle ground between Fedora and CentOS. Something with a life-time of ~2 years, with API increments etc. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
The entire QA team (and the entire anaconda team, for that matter) is currently spending virtually all its time trying to help bash the new anaconda into something vaguely resembling shape for a fairly arbitrary release deadline, so we can ship something called 'the Fedora 18 stable release' without *completely* corpsing Jimmy Fallon-style as we do the release announcement (sre, this is a stable release... *giggle* *giggle* *guffaw* *full-blown laughing fit*). We've barely looked at the desktop or the update mechanism or anything else. Stuff in Fedora regresses all over the place...there all sorts of weirdness in how fairly basic bits of our OS work, like updates and login and various other crap. We can't really look in a mirror and say that, say, Fedora 17 is a serious stable operating system release by any reasonable definition. It's a stable Fedora release, and we all know what that is. We had a feature for a smooth boot process back in F12, remember? where everything was polished and had the same background and you didn't see any mode transitions? How's that working these days? It was supposed to be a feature of our operating system. We almost got it done for one release, and have been consistently regressing it ever since. That's not what stable, mature operating systems do. Adam is telling the inconvenient truth here, and I agree. We really shouldn't pretend that Fedora is a stable OS. Unfortunately none of Linux distributions really is (now talking about desktop distributions, not server ones). But... the fact we're doing a poor job doesn't mean that some general users are not using Fedora happily. They may the lucky ones (no update breakages) or they have a power-user friend who help them from time to time. If we cut them off completely, I'm afraid Fedora would become a niche distribution, with just a fraction of its previous user base. I think that wouldn't be a good outcome. But I agree we need to simplify things and decrease the currently required resources (QA, package maintainers, releng, etc) so that the quality can go up. My idea would be to have two releases: == Fedora Stable == * A release for general users with low volume of security fixes and important bug fixes. ** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of updates. * Released every 18 months, supported for 18+2 months (2 months to give people time to upgrade to the next Fedora Stable). ** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH our package maintainers wouldn't probably like supporting 2-year-old packages. 18 months is still an increase from current 12 months of support, but if we stop releasing two parallel stable releases, we can make the support longer with the same energy spent. ** Just one stable release instead of two. Can anyone tell me a compelling argument for having two stable releases (F16, F17) in parallel? I don't see any. The current model probably evolved because we wanted new software fast, but upgrading every 6 months would discourage a lot of users. Let's be honest - yes, it will contain old packages and yes, it is intended for conservative users. For the other group we will have Fedora Rolling. * More reliable upgrades, although less convenient for power users. Instead of current way of often-broken system upgrades, our upgrade tool would install a clean system, remount /home, and try to install all GUI applications that the user had manually installed in his previous system. ** General user wouldn't see a difference, but we could achieve much higher upgrade success rate. ** Power users would have to manually transfer /etc changes, add custom repos, etc. But if you need to do that only once every 18 months, it's not so bad. Also, a lot of power users would use Fedora Rolling instead, so they would not be affected at all. Some power users can even do unsupported yum upgrades (as many of them do now), so they won't be affected by it either. * There would probably have to be a stabilization period before new Fedora Stable is released. So Branched release would exist for a short time. But it would be e.g. 3 months every 18 months, instead of current 3 months every 6 months. Also, with Fedora Rolling being generally working (as opposed to current Rawhide), the period could be much shorter: 1-2 months. == Fedora Rolling == * Rolling release similar to Fedora Branched, but with higher quality standards. This would target Linux power users wanting leading-edge software. ** Bodhi karma would be used for issuing updates. Because a lot of people would be using Fedora Rolling, the quality would be higher than current Fedora Branched (where just a tiny number of people actually run it and report problems). * Big disruptive changes (like usrmove or sysv-systemd) would be allowed to happen just in a concrete time slots, e.g. once a quarter. ** A special tool would
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 19:47 +0200, Alek Paunov wrote: On 04.11.2012 19:25, Simo Sorce wrote: note that this is also our strength in some respect because it allows the system to evolve a lot more quickly, but it also means upgrades are Indeed. simply going to break stuff, and that's not so great for desktop environments and scare the hell off of 3rd party vendors. You may notice we do not have many 3rd party vendors, I think ABI instability is reason number, 1, 2 and 3 of why we can't have reliable third parties with a community built OS. I agree completely with all your points. A possibly viable alternative for the ABIs freezing (which we can not ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers and 3rd parties with powerful source tools (API migration/checking), just like Google does internally, unsing the Clang tooling, witch was developed exactly for this purpose. The GCC/OpenJDK tooling development is not something appropriate as effort for the manpower of almost any upstream, but IMHO should be seen as important goal for relatively big player like Fedora. Unfortunately it won't work, unless you are ready to also go and mark reliable and unreliable upstreams, which is ... difficult. The reason I say so is that I know for sure not all upstreams are willing to maintain ABI compatibility. There are various degrees but some go for absolute ABI compatibility at all costs (glibc) to I'll break the ABI on purpose (or because I don't care) at every upgrade (won't try to name names). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 05, 2012 at 08:35:53 -0500, Kamil Paral kpa...@redhat.com wrote: My idea would be to have two releases: == Fedora Stable == * A release for general users with low volume of security fixes and important bug fixes. ** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of updates. Some packages need more than bug fix updates (unless you are taking a very broad view of what a bug is). We haven't done a very good job of having a consistent interpretation with the current update policy. Giving the proposal below, this will be a more important issue than it is now. * Released every 18 months, supported for 18+2 months (2 months to give people time to upgrade to the next Fedora Stable). ** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH our package maintainers wouldn't probably like supporting 2-year-old packages. 18 months is still an increase from current 12 months of support, but if we stop releasing two parallel stable releases, we can make the support longer with the same energy spent. We are going to take a marketing hit doing this. ** Just one stable release instead of two. Can anyone tell me a compelling argument for having two stable releases (F16, F17) in parallel? I don't see any. The current model probably evolved because we wanted new software fast, but upgrading every 6 months would discourage a lot of users. Let's be honest - yes, it will contain old packages and yes, it is intended for conservative users. For the other group we will have Fedora Rolling. We provide extra flexibility in letting users decide when they want to do upgrades to stay in support. It's not only letting them use a release for about a year if they want, but also to do the upgrade at a time where they can conveniently deal with any issues. * More reliable upgrades, although less convenient for power users. Instead of current way of often-broken system upgrades, our upgrade tool would install a clean system, remount /home, and try to install all GUI applications that the user had manually installed in his previous system. This seems to be independent of the proposal to have only one stable release. This tool is still not going to be able to do magic and there will be config things that still need to be redone. Third party repos will still be an issue. ** General user wouldn't see a difference, but we could achieve much higher upgrade success rate. Maybe. ** This process would also allow Anaconda devs to continuously work on the installer and update it continuously with core system changes. Currently they can't work on Rawhide because Rawhide is just broken. Fedora Rolling would allow them that. I don't think that is the issue. They work in branched because they don't have the man power to also be working in rawhide at the same time and since anaconda is sensitive to the version of other packages, they want to be developing against what's going to be in the next release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 5, 2012 at 5:56 AM, Jiri Eischmann eischm...@redhat.com wrote: Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. Or fp.org monthly stats. You would lose reviews, that are usually published after releases, because I don't see any reviews of rolling release distributions by main magazines. Etc. Documentation is another concern. It's hard to maintain static guides with a rolling release. The Arch Wiki is a great resource to be sure, but it's ever-changing and not easy to find old information if you're not running with current. The guides that the Fedora Docs group produce are a great resource for the community, and it would be a major strain on our resources to keep up with rolling releases. My personal opinion is that a rolling release might be nice (not nice enough, apparently to use Rawhide, but that's more about laziness than anything), but I'm not convinced it's what's best for the community at large. -- Ben Cotton Fedora Docs Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Tom Lane t...@redhat.com wrote: Simon Lukasik isim...@fedoraproject.org writes: Currently, each Fedora release is kept alive for 13(+/-) months. There were dozens of threads about shortening or prolonging period -- but I am not sure if something like the following has been ever discussed: Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. Additionally, maintainers might be encouraged to push their system wide changes into N%3==1. As well as they might be encouraged to make the Fedora N%3==0 their best bread. Wouldn't that just encourage 99% of average users to ignore the short-lived releases? It would sure be a damn tempting approach for me. (Personally, all I want out of Fedora is a stable platform to get my work done on, and the less often I have to reinstall, the better.) 99% is an overestimation. Personally I would prefer to update every 6 months just to have all the latest stuff, but if I support an organization with many Fedora installations I would choose the N%3==0 release, which would provide me only security updates after 7 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/02/2012 07:04 PM, Adam Williamson wrote: Sure, like I said in another mail, we've got better at that than before. But as I also said in the same mail, you still have to do a version upgrade every twelve months. That alone is ridiculous for a 'stable' operating system. This is an important point---it makes it difficult to deploy Fedora for other people. When the end-of-support comes, it usually means having to reinstall, because upgrade can take unbounded time, if problems pop up. Additionally, in my experience, a reinstall often results in a better configuration, free of grandfathered suboptimal settings. I keep thinking about a scheme to roll over an EOL Fedora into a closest possible CENTOS. It's not trivial because I can't just look for the CENTOS that matches the original Fedora release, because of the subsequent updates. It would have to look at the as-is system and try to figure out the best matching CENTOS release. I am thinking about a sum-of-squared-differences-like distance metric: calculate sum over all packages of (installed_version - CENTOS_X_version)^2, for several CENTOS_X versions, and chose the one giving the smallest value. Of course some packages (glibc, kernel) would have a higher weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
* A release for general users with low volume of security fixes and important bug fixes. ** Bug fixes would be pushed monthly and QA would be performed on this monthly batch of updates. Some packages need more than bug fix updates (unless you are taking a very broad view of what a bug is). We haven't done a very good job of having a consistent interpretation with the current update policy. Giving the proposal below, this will be a more important issue than it is now. You are right, some types of packages would deserve more frequent updates even if they are not just bugfixes. Typically end-user applications like Firefox or LibreOffice, if there is no major UI/functionality change. Fedora Stable is intended for conservative users, but it's still Fedora, so reasonable minor changes would be fine. * Released every 18 months, supported for 18+2 months (2 months to give people time to upgrade to the next Fedora Stable). ** Why 18 months? Because for general users it is annoying to upgrade every year, but OTOH our package maintainers wouldn't probably like supporting 2-year-old packages. 18 months is still an increase from current 12 months of support, but if we stop releasing two parallel stable releases, we can make the support longer with the same energy spent. We are going to take a marketing hit doing this. Probably yes. But, to tell the truth, we're getting a lot of marketing by postpoing F18 as well. There might be a lot of other ways to do marketing. ** Just one stable release instead of two. Can anyone tell me a compelling argument for having two stable releases (F16, F17) in parallel? I don't see any. The current model probably evolved because we wanted new software fast, but upgrading every 6 months would discourage a lot of users. Let's be honest - yes, it will contain old packages and yes, it is intended for conservative users. For the other group we will have Fedora Rolling. We provide extra flexibility in letting users decide when they want to do upgrades to stay in support. It's not only letting them use a release for about a year if they want, but also to do the upgrade at a time where they can conveniently deal with any issues. That's a good argument. Currently they have 7 months to do the upgrade. With my proposal, they have 2 months. Unless they want to run a system without security patches for some time. So maybe we could extend the time we provide security patches? * More reliable upgrades, although less convenient for power users. Instead of current way of often-broken system upgrades, our upgrade tool would install a clean system, remount /home, and try to install all GUI applications that the user had manually installed in his previous system. This seems to be independent of the proposal to have only one stable release. Right. This tool is still not going to be able to do magic and there will be config things that still need to be redone. Third party repos will still be an issue. It's a clean installation, I don't think it needs any magic. Also third-party repos are not a problem, we just ignore them and they won't influence the new system. People will add them manually again once in 18 months. ** This process would also allow Anaconda devs to continuously work on the installer and update it continuously with core system changes. Currently they can't work on Rawhide because Rawhide is just broken. Fedora Rolling would allow them that. I don't think that is the issue. They work in branched because they don't have the man power to also be working in rawhide at the same time and since anaconda is sensitive to the version of other packages, they want to be developing against what's going to be in the next release. Yes, but this would reduce the surprise moment when Fedora is being Branched and Anaconda team discovers that 1337 things changed in Rawhide since the last stable release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
This tool is still not going to be able to do magic and there will be config things that still need to be redone. Third party repos will still be an issue. It's a clean installation, I don't think it needs any magic. Also third-party repos are not a problem, we just ignore them and they won't influence the new system. People will add them manually again once in 18 months. There is desktop config in people's home directories that may not work with updated packages as expected. Package updates don't touch your /home. Clean install is the same as package updates in these regards. Custom configuation done in /etc is lost. How do they get the packages from the third party repos reinstalled? Fedora will probably be limited in doing this in a fully automated way, since there are legal issues. Please read my email again: ** Power users would have to manually transfer /etc changes, add custom repos, etc. But if you need to do that only once every 18 months, it's not so bad. Also, a lot of power users would use Fedora Rolling instead, so they would not be affected at all. Some power users can even do unsupported yum upgrades (as many of them do now), so they won't be affected by it either. It wouldn't be done automatically, no. All this stuff would have to be setup again manually. But that's just my view. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 05, 2012 at 13:23:59 -0500, Kamil Paral kpa...@redhat.com wrote: This tool is still not going to be able to do magic and there will be config things that still need to be redone. Third party repos will still be an issue. It's a clean installation, I don't think it needs any magic. Also third-party repos are not a problem, we just ignore them and they won't influence the new system. People will add them manually again once in 18 months. There is desktop config in people's home directories that may not work with updated packages as expected. Package updates don't touch your /home. Clean install is the same as package updates in these regards. But the updated packages may not like old configs. There is still potential for occasional problems there. Please read my email again: ** Power users would have to manually transfer /etc changes, add custom repos, etc. But if you need to do that only once every 18 months, it's not so bad. Also, a lot of power users would use Fedora Rolling instead, so they would not be affected at all. Some power users can even do unsupported yum upgrades (as many of them do now), so they won't be affected by it either. It wouldn't be done automatically, no. All this stuff would have to be setup again manually. But that's just my view. I was figuring that many people that enabled rpmfusion to get, say media codecs, would not fall into the power user category. /var is another tricky area. There are good and bad things about keeping and replacing it. Nothing we do is going to be perfect for going from one release to another. Putting more work into making that go smoothly is going to be useful as long as we have releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 5, 2012 at 6:34 PM, Bruno Wolff III br...@wolff.to wrote: It's a clean installation, I don't think it needs any magic. Also third-party repos are not a problem, we just ignore them and they won't influence the new system. People will add them manually again once in 18 months. There is desktop config in people's home directories that may not work with updated packages as expected. Package updates don't touch your /home. Clean install is the same as package updates in these regards. But the updated packages may not like old configs. There is still potential for occasional problems there. The way it might go is that if you have a package update which needs a new config then you have the update process install a config.rpmnew config file and add a note that due to the change a manual merge of old and new config files is needed - it is usually not more than a couple of minutes effort to do that - and provided that there is some advice that maybe even is in the yum output and in the yum log file with a simple summary of what is needed then it need not be a big deal - a simple wiki entry somewhere explaining how to use diff or vimdiff would work wonders for the majority of users to merge config files to keep up to date would not be too much effort would it? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
From: Jóhann B. Guðmundsson johan...@gmail.com On 11/05/2012 05:28 PM, Przemek Klosowski wrote: On 11/02/2012 07:04 PM, Adam Williamson wrote: Sure, like I said in another mail, we've got better at that than before. But as I also said in the same mail, you still have to do a version upgrade every twelve months. That alone is ridiculous for a 'stable' operating system. This is an important point---it makes it difficult to deploy Fedora for other people. When the end-of-support comes, it usually means having to reinstall, because upgrade can take unbounded time, if problems pop up. Additionally, in my experience, a reinstall often results in a better configuration, free of grandfathered suboptimal settings. I keep thinking about a scheme to roll over an EOL Fedora into a closest possible CENTOS. It's not trivial because I can't just look for the CENTOS that matches the original Fedora release, because of the subsequent updates. It would have to look at the as-is system and try to figure out the best matching CENTOS release. I am thinking about a sum-of-squared-differences-like distance metric: calculate sum over all packages of (installed_version - CENTOS_X_version)^2, for several CENTOS_X versions, and chose the one giving the smallest value. Of course some packages (glibc, kernel) would have a higher weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)). Well I personally would rather have centos and other rhel clones unite to support a lts release of Fedora instead since it does not take more then a missing sysadmin or rhel business decision to more or less render those community incapacitated +1 This is exactly why I've never adopted one of them. Like the concept, but fear such situations. I'd love to have a LTS for my servers and have something like a rolling Fedora release for *my* workstations. Other workstations that I help support, perhaps something in between. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 4 November 2012 23:57, drago01 drag...@gmail.com wrote: On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote: On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote: On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Adam, this is plainly untrue for Microsoft, they always supported upgrading to the next version. As someone already pointed out, 'support' is an overloaded term. They 'support' upgrades the same way we 'support' upgrades - they provide an upgrade mechanism for you to hang yourself with. As was clarified later, the point is that they don't guarantee it will work, [citation needed] I can't believe that they were selling something windows X upgrade without supporting it at all. That's like selling a car and telling the customer it might not move at all in that case you are on your own sorry. I only have my personal experience because trying to find the exact line in the tiny print which covers it requires me to know more legal terms than I do. The scenarios I have run into multiple times is where a manager decided to not pay Microsoft for their upgrade support and ended up with having to pay for some sort of tiger team to figure out what went wrong. Usually it is not with the core OS.. that upgrades fine.. it is usually with registry and non-core programs OR it might be hardware drivers for anything above the basics . At which point Microsoft will point you towards the OEM or software group that manufactures that software.. which is very fun when that is Microsoft itself. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 05.11.2012 15:57, Simo Sorce wrote: A possibly viable alternative for the ABIs freezing (which we can not ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers and 3rd parties with powerful source tools (API migration/checking), just like Google does internally, unsing the Clang tooling, witch was developed exactly for this purpose. The GCC/OpenJDK tooling development is not something appropriate as effort for the manpower of almost any upstream, but IMHO should be seen as important goal for relatively big player like Fedora. Unfortunately it won't work, unless you are ready to also go and mark reliable and unreliable upstreams, which is ... difficult. The reason I say so is that I know for sure not all upstreams are willing to maintain ABI compatibility. There are various degrees but some go for absolute ABI compatibility at all costs (glibc) to I'll break the ABI on purpose (or because I don't care) at every upgrade (won't try to name names). My point was about the second group (dependency providers with evolving ABIs) and more specifically about the affected packages (their users - dependency consumers). When the consumers are short on resources or just don't really care so much about the current Fedora consistency, the problem naturally lands at the responsibility of the respective Fedora maintainers. The whole dance would be sufficiently different if we provide the cooperative upstreams with powerful tools for aligning their projects with the current/prepared release compound ABI. IMO, this means Fedora VMs (not necessarily sponsored by the project, I am sure that the Cloud SIG has enough magic at hand to orchestrate community/upstreams provided instances) and preinstalled compiler plugins based tooling - easy to use instruments for checking and fixing their sources according the release environment state. The above applies also for the third parties (propriety software vendors and these with open source licenses but not so open style of development) - they probably will spent few dozens of hours to lint, once we provide them with ready to use login and type 'make' environment. Of course, not any upstream would be willing to cooperate - in this case we will have to handle the issue with our own resources, but again the tooling can reduce the time spent by the packagers with an order of magnitude. Fedora is almost always the First, once we start doing this proactive Upstreams alignment technology and effort, maybe other Linux OS vendors would join too. Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit : On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Thanks, Mike, that's a great illustration of the point I was trying to make: the Arch model sounds much like what I was trying to suggest for Fedora, a simple two-track 'devel' and 'stable' model with QA between the tracks. And as you point out, on the face of it it appears to involve much less drudgery for maintainers. I have never run Arch, but I do get the general impression it provides a sufficiently reliable experience for the kinds of users Fedora and Arch have. Unfortunately, we do not have enough people doing QA for the model to work. Each time I run fedora-easy-karma on branched, I have the feeling to see always the same names ( ie, you and kevin ). I would be interested to see some stats about this, because the difference between a unused software and one who have no bug is thin. And I am doubting that changing the release model will suddenly make people do QA. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/04/2012 12:17 PM, Michael Scherer wrote: Le samedi 03 novembre 2012 à 09:29 -0700, Adam Williamson a écrit : On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Thanks, Mike, that's a great illustration of the point I was trying to make: the Arch model sounds much like what I was trying to suggest for Fedora, a simple two-track 'devel' and 'stable' model with QA between the tracks. And as you point out, on the face of it it appears to involve much less drudgery for maintainers. I have never run Arch, but I do get the general impression it provides a sufficiently reliable experience for the kinds of users Fedora and Arch have. Unfortunately, we do not have enough people doing QA for the model to work. Each time I run fedora-easy-karma on branched, I have the feeling to see always the same names ( ie, you and kevin ). I would be interested to see some stats about this, because the difference between a unused software and one who have no bug is thin. And I am doubting that changing the release model will suddenly make people do QA. Adam's point is that reducing the number of branches requiring QA should permit more thorough QA with the scarce resources available, resources which currently are spread too wide and too thin with the current model. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/03/2012 12:30 AM, Simo Sorce wrote: On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote: * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS On some stable OSs you cannot upgrade *at all*. It is true that some OSs are maintained for longer time. A short release cycle puts a lot more emphasis on working updates, but to be honest I haven't had huge issues with Fedora, no more than I used to with debian/ubuntu There are some cases were it went south on some releases and I had to manually handle it. But then if that's a problem we could simply create a /home partition by default and users can choose to reinstall just the OS and keep the /home intact. For a desktop that should be ok in all cases where you fear an upgrade would be too dangerous. * We do not insist on a level of polish or lack of functional regression in our stable releases which is any way consistent with a true productized general purpose OS Maybe if we cut stable releases to 1 we can improve this ? The only real reason we maintain N-2 is that forcing a 6mo update on everyone is just ridiculous, but a 1y cycle seems reasonable enough, and with a rolling devel release there would be less reason for frequent stable releases. I like where this is going, here is another view or counter proposal to rolling updates. Currently, each Fedora release is kept alive for 13(+/-) months. There were dozens of threads about shortening or prolonging period -- but I am not sure if something like the following has been ever discussed: Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. Additionally, maintainers might be encouraged to push their system wide changes into N%3==1. As well as they might be encouraged to make the Fedora N%3==0 their best bread. -- Simon Lukasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Panu Matilainen pmati...@laiskiainen.org writes: On 11/04/2012 12:17 PM, Michael Scherer wrote: And I am doubting that changing the release model will suddenly make people do QA. Adam's point is that reducing the number of branches requiring QA should permit more thorough QA with the scarce resources available, resources which currently are spread too wide and too thin with the current model. I understand his hope that it would help, but TBH I think it would make things worse not better. Consider: * Currently, we get barely-adequate QA on the frontmost Fedora branch and none to speak of on the back branches. (Certainly for my packages, the standard update cycle is push update to testing, wait however long bodhi makes me wait, push to stable because nobody ever adds any karma except maybe in the latest branch.) That's tolerable, actually, because you're not supposed to push anything but low-risk bugfix updates into the back branches. If you think it needs testing you probably shouldn't be pushing it there. * In a rolling release model, however, major changes are supposed to eventually get pushed into all the branches. Each time one gets pushed further back, an appropriate amount of QA would need to get done, if you want to have any expectation of not breaking that branch. This looks like *more* QA to me, not less. The core problem I see here is that in a rolling-release environment, there's nothing to ensure that major multiple-package-affecting changes hit the stable branches in a consistent order. That means that each time you push one back, you are creating a unique new package set with a unique new set of potential issues, and that's why QA would actually be needed. Now it's easy to see how to avoid that: force consistency. But that idea leads you right back to the series-of-releases approach that we have now. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Simon Lukasik isim...@fedoraproject.org writes: Currently, each Fedora release is kept alive for 13(+/-) months. There were dozens of threads about shortening or prolonging period -- but I am not sure if something like the following has been ever discussed: Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. Additionally, maintainers might be encouraged to push their system wide changes into N%3==1. As well as they might be encouraged to make the Fedora N%3==0 their best bread. Wouldn't that just encourage 99% of average users to ignore the short-lived releases? It would sure be a damn tempting approach for me. (Personally, all I want out of Fedora is a stable platform to get my work done on, and the less often I have to reinstall, the better.) I think what you'd have using the short-lived releases is just the same kind of brave souls who are willing to run rawhide or pre-release branched systems. And there aren't that many of them, so you'd get little QA, which would help to ensure those releases remain buggy, thus creating a nasty feedback loop that further helps to drive away people whose main interest is not in helping to debug the system. Eventually the short-lived releases would just be rawhide-with-a-different-name. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 04.11.2012 17:05, schrieb Tom Lane: Simon Lukasik isim...@fedoraproject.org writes: Currently, each Fedora release is kept alive for 13(+/-) months. There were dozens of threads about shortening or prolonging period -- but I am not sure if something like the following has been ever discussed: Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. Additionally, maintainers might be encouraged to push their system wide changes into N%3==1. As well as they might be encouraged to make the Fedora N%3==0 their best bread. Wouldn't that just encourage 99% of average users to ignore the short-lived releases? It would sure be a damn tempting approach for me. (Personally, all I want out of Fedora is a stable platform to get my work done on, and the less often I have to reinstall, the better.) why is it not considered to change the release cycle from 6 to 12 months? for large changes this would be daramtically less pressure to any contributor and give time to polish the changes instead release them in hurry as often happended (systemd, GNOME3 as examples) IMHO there could be something done for non-destructive updates like LibreOffice as for the kernel which is a recent one since a really long time and it works mostly good signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Adam, this is plainly untrue for Microsoft, they always supported upgrading to the next version. Just take a look at this - MS rocks here http://www.youtube.com/watch?v=vPnehDhGa14 However keep in mind, that in MS case the OS, is *a lot* smaller than what we have. They do not give any guarantee that third party apps will keep working although they *do* do their damn best to make sure they don't break most important stuff. (By simply not changing interfaces, ABIs, or adding compatibility libraries in the system). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote: much lower levels of churn, No they actually have way higher levels of churn ... just think about it ... in fedora we are talking about 6 months worth of chrun not 5+ years. Can't speak for Red Hat but maybe this is one of the reasons why they don't support upgrades. nope, Adam is right, the level of churn is *a lot* lower. Microsoft rarely changes existing components, and never breaks ABIs no matter what, at most they add new stuff. And when they do need to make a lower level change they design it in early stages and then spend a lot of time testing even 3rd party apps to make sure they don't break them all, and for more popular ones they even built workarounds in the system so they don't break. Also their package set is a lot smaller. They do not package a lot of applications like we do. However the main differentiator is ABI stability, MS simply has a *lot* less issues on upgrades because they have an ABI stability that we can only dream of, in the FOSS world. The only component that is comparable is the kernel. Almost everything else in user space is just not comparable. note that this is also our strength in some respect because it allows the system to evolve a lot more quickly, but it also means upgrades are simply going to break stuff, and that's not so great for desktop environments and scare the hell off of 3rd party vendors. You may notice we do not have many 3rd party vendors, I think ABI instability is reason number, 1, 2 and 3 of why we can't have reliable third parties with a community built OS. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 04.11.2012 19:25, Simo Sorce wrote: note that this is also our strength in some respect because it allows the system to evolve a lot more quickly, but it also means upgrades are Indeed. simply going to break stuff, and that's not so great for desktop environments and scare the hell off of 3rd party vendors. You may notice we do not have many 3rd party vendors, I think ABI instability is reason number, 1, 2 and 3 of why we can't have reliable third parties with a community built OS. I agree completely with all your points. A possibly viable alternative for the ABIs freezing (which we can not ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers and 3rd parties with powerful source tools (API migration/checking), just like Google does internally, unsing the Clang tooling, witch was developed exactly for this purpose. The GCC/OpenJDK tooling development is not something appropriate as effort for the manpower of almost any upstream, but IMHO should be seen as important goal for relatively big player like Fedora. Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote: On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Adam, this is plainly untrue for Microsoft, they always supported upgrading to the next version. As someone already pointed out, 'support' is an overloaded term. They 'support' upgrades the same way we 'support' upgrades - they provide an upgrade mechanism for you to hang yourself with. As was clarified later, the point is that they don't guarantee it will work, and in practice, it doesn't work reliably enough for anyone doing anything really critical to rely on it. And they don't. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/04/2012 05:05 PM, Tom Lane wrote: Simon Lukasik isim...@fedoraproject.org writes: Currently, each Fedora release is kept alive for 13(+/-) months. There were dozens of threads about shortening or prolonging period -- but I am not sure if something like the following has been ever discussed: Each N-th Fedora release -- where N%3==1 -- is alive for 7 months. Each N-th Fedora release -- where N%3==2 -- is alive for 7 months. Each N-th Fedora release -- where N%3==0 -- is alive for 19 months. Additionally, maintainers might be encouraged to push their system wide changes into N%3==1. As well as they might be encouraged to make the Fedora N%3==0 their best bread. Wouldn't that just encourage 99% of average users to ignore the short-lived releases? It would sure be a damn tempting approach for me. (Personally, all I want out of Fedora is a stable platform to get my work done on, and the less often I have to reinstall, the better.) If You are suggesting that the majority of our users would prefer stability over features..well, in that case we may have something to think about. I think what you'd have using the short-lived releases is just the same kind of brave souls who are willing to run rawhide or pre-release branched systems. And there aren't that many of them, so you'd get little QA, which would help to ensure those releases remain buggy, thus creating a nasty feedback loop that further helps to drive away people whose main interest is not in helping to debug the system. Eventually the short-lived releases would just be rawhide-with-a-different-name. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
For microsoft perhaps, but Ubuntu, Debian ? Upgrading from a release to the next is trivial, and in general work well. Sure, probably the update to the core system component is more light, no Usrmove, no systemd, or something like this. And preserving, updating the new configuration based on the previous really is not so simple. But this problem today is really well solved if you use a good configuration manager, but this is not applicable for a general end user, i think. Best and sorry for the top posting. 2012/11/4, Simo Sorce s...@redhat.com: On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Adam, this is plainly untrue for Microsoft, they always supported upgrading to the next version. Just take a look at this - MS rocks here http://www.youtube.com/watch?v=vPnehDhGa14 However keep in mind, that in MS case the OS, is *a lot* smaller than what we have. They do not give any guarantee that third party apps will keep working although they *do* do their damn best to make sure they don't break most important stuff. (By simply not changing interfaces, ABIs, or adding compatibility libraries in the system). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Inviato dal mio dispositivo mobile -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
- Original Message - From: Bruno Wolff III br...@wolff.to To: Kevin Fenzi ke...@scrye.com Cc: devel@lists.fedoraproject.org Sent: Saturday, November 3, 2012 7:37:45 PM Subject: Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))) On Sat, Nov 03, 2012 at 11:11:18 -0600, Kevin Fenzi ke...@scrye.com wrote: In any case, I think we do need to look at release cycle changes or at the very least Feature process revamp. And get comments from other than developers. Marketting might have serious concerns about the loss of exposure not having releases would result in. This is a very valid argument. I understand this is a devel list, so we should stay on the technical level, but if we discuss such broad changes that affect the whole project, we should also take into account other aspects. Switching to rolling release would have a *huge* negative impact on marketing! It's releases what makes the fuzz and their announcements get beyond our current user base. We would have no release parties, no codenames. We would lose the product. I wonder what impact it would have on Fedora adoption by cloud providers. I think it's much more understandable not only for them, but also for their customers to take Fedora 17 than some monthly build. I personally don't like the whole idea of switching to rolling release. Although I see some pros, I see a lot of cons that would outweight the pros. I've come across a few rolling release distributions (Debian Testing, Arch Linux, Gentoo,...) and I don't think they work if you want to achieve some level of stability and predictability. I rather see some changes in Rawhide so that it becomes a usable distribution that people more interested in bleeding edge can use. Because now Rawhide does not even serve testing purposes because almost no one is using it. It'd like to see its stability on the level where Fedora branched is now (it's not a smooth experience, you should expect problems, use skip-broken from time to time, but it's usable). Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann jeisc...@redhat.com wrote: This is a very valid argument. I understand this is a devel list, so we should stay on the technical level, but if we discuss such broad changes that affect the whole project, we should also take into account other aspects. Switching to rolling release would have a *huge* negative impact on marketing! It's releases what makes the fuzz and their announcements get beyond our current user base. We would have no release parties, no codenames. We would lose the product. I wonder what impact it would have on Fedora adoption by cloud providers. I think it's much more understandable not only for them, but also for their customers to take Fedora 17 than some monthly build. Does anyone have any reliable statistics about the number of users who feel that release parties and codenames are important to them? There will no doubt be some people for whom the idea of running a particular codenamed release is important - but there will also be others for whom a high quality established linux distribution that is reliable and up to date irrespective of its codename is more important. Marketing feedback if it is possible to give the relative number of users in each camp would be helpful here? Gathering such statistics is likely difficult though. I personally don't like the whole idea of switching to rolling release. Although I see some pros, I see a lot of cons that would outweight the pros. I've come across a few rolling release distributions (Debian Testing, Arch Linux, Gentoo,...) and I don't think they work if you want to achieve some level of stability and predictability. Arch linux is stable and reliable and predictable - I use it every day - you need to ask users of the other distributions named whether users feel they are similarly stable and predictable or not for the most part. Does anyone have any relative user stats on the various distros? Do any web sites gather stats which might indicate hit rates coming from different distros? These data are difficult to get so in the end a clear goal for any distribution has to be agreed on and then executed - if Fedora wishes to go to rolling Rawhide but a bit more stable that at present and it is possible to do that - then developers must agree at least on some kind of overall vote maybe? In the end the users will guide whether the route taken is being adopted widespread among the community. You get some idea of users interested from feedback to the devel list, or via bodhi I guess? One other question that is hard to answer is whether a particular change in direction is achievable since it depends on developers adopting it and agreeing to work on it - inevitably some will not want to go to any new route - but will the new direction excite other developers to come on board that were not there before and make up any loss? The way I see it is that the two routes are a bit like asking if people like meat or fish for the main course at a meal - there will be a split opinion - and there are good points about both! Some people may be allergic to one or other though! Is there an objective list of pros and cons that can be judged without bias in favour of rolling release or periodic releases so that a logical weighing of the relative merits of both approaches can be considered? If that goes in favour of rolling release then can it be achieved with the tools available without too much effort? If new tools have to be built within the Fedora Framework is there enough effort and willingness to build them? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 02 Nov 2012 20:55:38 +, Jóhann B. Guðmundsson wrote: and one stable release ( valid for 2 maybe 3 years ) for those in the community that want something they dont constantly having to upgrade to and can deploy on their servers. ( ofcourse to have a stable release we first and foremost would need maintainers willing to maintain the distribution for that time, epel could maybe be simply dropped for that ). That's called CentOS, and I am not sure what sense it makes it to recreate the same thing again ... if anything than we should concentrate more on EPEL, so everything required is covered. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 02 Nov 2012 13:22:21 -0700, Adam Williamson wrote: I disagree. It's usable by the kind of people who use Fedora. Who like shiny cutting-edge stuff and don't mind dealing with wonkiness constantly. I wouldn't dream of putting any regular person on a Fedora install, quite frankly. It's easy to get into a perspective bubble where Fedora looks normal, but it isn't. It is not a stable general-purpose operating system and it's absurd to represent it as such. I wouldn't put Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is just your hackneyed old 'regular person' example) and say 'there's your computer'. How many of us would? Even if you get a good Fedora release Completely agree with Adam ... I was working on the solution for my family (both my wife and kids are on Linux, of course). After having my wife on Fedora for some time and listening to her constant complaints about awful amount of updates she doesn't care for and doesn't want to have installed all the time (BTW, could somebody fix PackageKit updates so that it actually can keep system updated for a long period of time without needed intervention on the command line from time to time?). In the end I have switched her to CentOS+EPEL+some-rpmfusion-packages-which- were-not-avaliable and she is a very happy lady. Updates are reasonable and system will hopefully hold together for a long time. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, Nov 4, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote: On Sun, 2012-11-04 at 12:18 -0500, Simo Sorce wrote: On Sat, 2012-11-03 at 00:36 +0100, Michał Piotrowski wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Adam, this is plainly untrue for Microsoft, they always supported upgrading to the next version. As someone already pointed out, 'support' is an overloaded term. They 'support' upgrades the same way we 'support' upgrades - they provide an upgrade mechanism for you to hang yourself with. As was clarified later, the point is that they don't guarantee it will work, [citation needed] I can't believe that they were selling something windows X upgrade without supporting it at all. That's like selling a car and telling the customer it might not move at all in that case you are on your own sorry. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
* drago01 [05/11/2012 08:00] : That's like selling a car and telling the customer it might not move at all in that case you are on your own sorry. This is par the course for proprietary software (with the added bonus that you can't actually fix it since you don't have the source code). Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Mon, Nov 5, 2012 at 8:02 AM, Emmanuel Seyman emman...@seyman.fr wrote: * drago01 [05/11/2012 08:00] : That's like selling a car and telling the customer it might not move at all in that case you are on your own sorry. This is par the course for proprietary software (with the added bonus that you can't actually fix it since you don't have the source code). The point here is that they are *selling* it ... you might not have the source code but if it does not work at all you can return it back and get a refund. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote: I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Who like shiny cutting-edge stuff and don't mind dealing with wonkiness constantly. I mind. So do many Fedora users and contributors, who want a shiny *stable* leading edge (not bleeding edge) linux distribution. I wouldn't dream of putting any regular person on a Fedora install, quite frankly. It's easy to get into a perspective bubble where Fedora looks normal, but it isn't. It is not a stable general-purpose operating system and it's absurd to represent it as such. I understand that regular users are not Fedora's main target, but it is a general-purpose operating system in the sense that it can be used by people who want to have a stable working environment with all the latest things from the Open Source world. In that sense, and from my point of view, if we had to rethink our release model and dedicate time and energy on a new approach, it would make more sense to have an extended support release (providing only security updates after 13 months) which is vital for the enterprise desktop market. Of course this is not in contradiction with having a rolling release model alongside, but I didn't know if we have enough human capacity to do them both. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 2, 2012 at 10:31 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 02 Nov 2012 15:17:02 -0700 Adam Williamson awill...@redhat.com wrote: ..snip... In my experience, in the last few years, Fedora stable releases have become much more stable. My stable boxes here at home I have not really had to poke at since I upgraded them to Fedora 17. I apply updates every few days and things keep working along fine. In previous cycles there were some real nasty brown paper bag type blowups that required me to do things to downgrade or tweak to keep my stable version working, that (knock on wood) hasn't happened in f16/f17 in my experence. I realize there are bugs and problems that hit, but I think the stable updates policy has helped keep those down. (Cue KevinK to come in and shout and tell me how wrong I am, etc etc) I'm personally -1 to any kind of rolling release beyond rawhide. There are distributions where a rolling release works very well indeed. Perhaps I could inject a couple of lines to think about since I use both Fedora and Archlinux: In Fedora what is maintained are 1) Two current releases with stable updates repos for each. 2) Updates-testing repos for both current stable releases and 3) Rawhide where volunteer users can expect potential major breakages periodically. That is five repos of packages. In Fedora to keep up to date users need a complete re-install either every year or every six months on every machine that runs Fedora. In Archlinux there are two repos - [core] and [testing] - once packages have been QA tested in [testing] then developers can move packages to [core] when they feel there is minimal risk of major failure for users of the stable repos. In Archlinux to keep up to date users need never do a full re-install again - but there are occasional periods when configs need to be tinkered with or manual commands entered as root when a major package upgrade takes place such as glibc or one or two major packages but this is only occasional. Provided users keep monitoring the news announcements where manual intervention is required then they have a system where virtually all major packages are upstream current or close to that. A complete re-install takes some hours for each machine (or indeed a yum preupgrade or similar as well) - manual intervention for the occasional major update to packages in arch linux takes some minutes usually at most. For users responsible for a significant number of machines having a rolling release knowing that all major packages are upstream current or close to that is a major advantage, and time saving, compared to Fedora's need for major upgrade of the system or re-install. Fedora is a bit simpler to install for less experienced users but for experienced linux admins an arch install is not a major issue. Both Fedora and Archnlinux are generally cutting edge if they are kept updated - but the effort to keep updated is very different. Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Some discussion and thought about these issues are pertinent to the discussion in this thread. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 12:37 PM, Henrique Junior henrique...@gmail.com wrote: It is difficult, for example, to understand why we have to wait until the next release to have LibreOffice 3.6, since this seems an non disruptive update that could bring major improvements in the productivity of users who rely on office suites to work. Well that's because we do not make a clear distinction between operating system and applications. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 02, 2012 at 16:32:00 -0700, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote: In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then a week later they deal with bar-1.0 to bar-2.0, then a week later they deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, everyone gets to deal with foo, bar, monkeys and five hundred other changes all at once. Which is chaos on a stick. A key difference though is that with actual releases people can do the upgrade at a good time for them to do it. With a rolling release bad things can happen at especially inconvenient time. I'd rather see us do a better job with rawhide so that more people use it and a better job at making upgrades go smoother so that people just trying to get stuff done with Fedora have a better experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 03, 2012 at 12:35:08PM +0200, Nikos Roussos wrote: I understand that regular users are not Fedora's main target, but it is a general-purpose operating system in the sense that it can be used by people who want to have a stable working environment with all the latest things from the Open Source world. While regular users are not Fedora's main target, our target user base assumes a general productivity user, including these characteristics: We expect the majority of users to be interested in a set of general productivity tasks. These tasks are usually non-technical in nature. They involve communication and the creation, storage, location, and viewing of content. They are common to both novice and experts alike, and we should deliver a platform that allows users to engage in these tasks without interruption or disruption. Which I think supports your position. (Leading edge, not bleeding edge.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote: On Sat, Nov 3, 2012 at 12:58 AM, Adam Williamson awill...@redhat.com wrote: My position is that the people who use Fedora and the kind of people we really _want_ to use Fedora can cope with it. Maybe the majority can maybe they can't. But as evident by this thread even fedora *developers* don't want to deal with such stuff. I think some of them were rather misunderstanding my point and my suggestion, which was my fault for phrasing my initial mail in an overly negative way (that I didn't realize until I read it back). But rather get work done. Do you really think that users are that much different? I don't think rolling release and getting work done are incompatible. As I mentioned, I run Branched permanently on my desktop - so it rolls from 'pre-Alpha' state through to 'stable' state briefly and then back to 'pre-Alpha' again, on a constant loop - and I do almost all my work on that. We could build a light rolling-release distro that was substantially more reliable than that. Again, my fundamental point is that we could achieve a sufficient level of reliability for Fedora's purposes - the same level of reliability we currently achieve, which I think the kinds of people we're talking about are happy with - on a lighter release model than 'do a stable release every six months come hell or high water' or 'three-track rolling, Debian style, with a very slow-moving stable track'. Remember, I'm not proposing it be as bad as Rawhide; we have the whole Bodhi karma process to work with. I think it's plausible to design a process where people only rarely have trouble with updates, even ones that are theoretically pretty messy; about the same frequency they'd have had trouble with upgrading our stable releases. That basically means you don't release anything and just release a huge update every six months. Don't really see what this gains us other then installation becoming an untested path. The installation process and images have to be up2date though to be able to deal with current hardware. Eh? That's not what I said at all. What I said was that I think in a well-managed rolling release model, users would actually run into trouble only about as often as they already do anyway. I don't mean they'd only get updates every six months, I mean they'd only get updates which _broke stuff_ on average every six months. Or less. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Thanks, Mike, that's a great illustration of the point I was trying to make: the Arch model sounds much like what I was trying to suggest for Fedora, a simple two-track 'devel' and 'stable' model with QA between the tracks. And as you point out, on the face of it it appears to involve much less drudgery for maintainers. I have never run Arch, but I do get the general impression it provides a sufficiently reliable experience for the kinds of users Fedora and Arch have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: The guys behind openSUSE created a good approach with Tumbleweed. By adding this repo users can opt-in to the (semi)rolling model. Tumbleweed is more like a pool where updated, stable, non disruptive software can be installed and I was able to talk to the guy who created Tumbleweed some time ago. He said that it is easy to maintain and takes only a few minutes a day to check things. It is difficult, for example, to understand why we have to wait until the next release to have LibreOffice 3.6, since this seems an non disruptive update that could bring major improvements in the productivity of users who rely on office suites to work. I don't think that *adding* tracks is an approach that is going to solve any of our problems, though it might add convenience for a small set of users. We need to be making things simpler, not more complex. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 03.11.2012 01:09, schrieb Adam Williamson: On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote: Am 03.11.2012 00:58, schrieb Adam Williamson: Microsoft don't really expect you to upgrade Windows. They expect you to buy a computer with Windows X on it, use it for three years, then throw it away and buy a new computer with Windows Y on it. Red Hat expects something similar for RHEL - they don't expect people to upgrade systems from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS migrations, which usually involve buying new hardware, not upgrading existing systems. This is an implicit acknowledgment that upgrades are just not a great way to do things. I don't think we can realistically expect Fedora to do it massively better. If you're going to do stable releases of your operating system, it just doesn't make a lot of sense to make people upgrade every twelve months. If you're going to have stable releases, you should maintain them long enough that people don't really rely on the upgrade function. That seems to be how the big boys do it. If we can't do that, are the stable releases really achieving much? look below, i prove you the opposite Please keep in mind the overall argument I'm making here. I'm not interested in trivial point-scoring. I have machines that have been upgraded for a long time too. Your mail doesn't really speak to the higher level questions here the overall argument of MINE is Fedora IS stable Fedora CAN be upgraded Fedora has a good overall level of upgrades these things have to be improved and not thrown away by we are doing it not good enough, so we stop doing it and i am sure one big improvement would be to relax the meaning of a release-date, often it is OK and there are no large blockers, sometimes it is not so easy at that is the time where free software without marketing bullshit have the valif option to say WE DELAY THE NEXT VERSION TO A UNKNOWN POINT IN TIME IT WILL HAPPEN WHEN IT IS READY FOR IT in the meantime the current release would be maintained only with real important updates like security as it is done for F17/F17 now and ALL users would be happy signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 03.11.2012 11:35, schrieb Nikos Roussos: In that sense, and from my point of view, if we had to rethink our release model and dedicate time and energy on a new approach, it would make more sense to have an extended support release (providing only security updates after 13 months) which is vital for the enterprise desktop market. THAT would make sense if there is a upgrade path between two LTS releases - let's say the cycle is two years there would be 4 normal release cycles and if features with the impact of systemd are startet after the release of a LTS you have the full 2 years to polish it AND many users would also use the current leading edge releases to be first a comination of both would be really perfect signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 03 Nov 2012 09:26:43 -0700 Adam Williamson awill...@redhat.com wrote: I don't think rolling release and getting work done are incompatible. As I mentioned, I run Branched permanently on my desktop - so it rolls from 'pre-Alpha' state through to 'stable' state briefly and then back to 'pre-Alpha' again, on a constant loop - and I do almost all my work on that. We could build a light rolling-release distro that was substantially more reliable than that. But I think that might be a non representative case. Before branched happens currently you get all the stuff like: Mass rebuilds, major upgrades that take a bunch of work to get all done, etc. So, you might not be considering them in your view above... but if we were rolling then you would have to deal with new boost, or png changing, or rpm format changing, etc, and there is seldom a way to cut these up into smaller bits. So, in a rolling release when say png changes, we would have to push all that change out to users in a big chud. They would have to do them somewhat quickly if they wanted any updates that would be depending on it/behind it. Again, my fundamental point is that we could achieve a sufficient level of reliability for Fedora's purposes - the same level of reliability we currently achieve, which I think the kinds of people we're talking about are happy with - on a lighter release model than 'do a stable release every six months come hell or high water' or 'three-track rolling, Debian style, with a very slow-moving stable track'. I'm not convinced. ;) In any case, I think we do need to look at release cycle changes or at the very least Feature process revamp. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 18:26, Adam Williamson wrote: On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote: Eh? That's not what I said at all. What I said was that I think in a well-managed rolling release model, users would actually run into trouble only about as often as they already do anyway. I don't mean they'd only get updates every six months, I mean they'd only get updates which _broke stuff_ on average every six months. Or less. Adam, I think that the current rolling release discussion as many other high interest general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. You mostly talk about the uncle Bob's profile (witch is the 2nd most present profile across the forums); Our vocal member Reinald belongs to one of the psychological subtypes of the mad sysadmin profile; Tom, which said yesterday that he would not be interested in rolling Fedora, into third profile, etc. BTW, personally I think, the uncle Bob profile currently most suffers the lack of the real package manager interface (at least under Gnome, I do not have a clue for KDE) - I see this issue as one with even high priority for uncle Bob than the lack of smooth upgrade scenario. So, my concrete proposal is to postpone all general discussions for a little, up to the moment when we describe as much as possible in detail let's say 16 Fedora user profiles and sub-profiles (at least on the wiki) and estimate somehow their population (may be along with the project leaders concept about the profiles witch Fedora actually is intended to seek for). Without any data at hand to back the prioritization and approach variant efficiency/suitability claims, I think it looks impossible to be achieved any level of consensus (especially in that list, as you know far better than me). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 19:17, Alek Paunov wrote: Adam, I think that the current rolling release discussion as many other high interest general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. Just because I said general ones which might be somewhat misleading, several examples: * The importance of Secure Boot workaround (in the proposed form) * The amount of the negative impact of /tmp on ramfs feature * The importance of a Software Center existence etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 03, 2012 at 11:11:18 -0600, Kevin Fenzi ke...@scrye.com wrote: In any case, I think we do need to look at release cycle changes or at the very least Feature process revamp. And get comments from other than developers. Marketting might have serious concerns about the loss of exposure not having releases would result in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 4:29 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-11-03 at 11:28 +, mike cloaked wrote: Others may wish to compare Fedora with other distributions also - but one thought I had was that in Archlinux there are only two repos to maintain - whilst in Fedora it is 5 repos! One might wonder whether there is less effort needed to keep up to date by the developers in Arch or Fedora - I don't have the answer to that question but the devs have more knowledge about effort needed to maintain all of this to make a proper comparison? Thanks, Mike, that's a great illustration of the point I was trying to make: the Arch model sounds much like what I was trying to suggest for Fedora, a simple two-track 'devel' and 'stable' model with QA between the tracks. And as you point out, on the face of it it appears to involve much less drudgery for maintainers. I have never run Arch, but I do get the general impression it provides a sufficiently reliable experience for the kinds of users Fedora and Arch have. Indeed Adam - I guess the choice for running a rolling release or periodic stable releases, with updates for some support period, is a choice that the collective developers need to make, and which then developers are happy to work with or move to where they feel comfortable. Having said that, it is clear that both Archlinux and Fedora are mainstream distributions each with significant numbers of users who treat their installs with sufficient confidence to use their systems on a day to day basis as a stable platform. Some Fedora people also run with the updates-testing repo enabled (or in the case or arch with [testing] enabled) and are ready to fix problems as they arise with occasional not-completely-stable updates from time to time. I have only been running archlinux on three machines for less than a year but I am pretty happy with the way updates arrive and delighted that, when major upgrades of desktop packages are released upstream, it is not too long before they are tested and released to [core] so it is nice to have the very latest KDE for example, and the latest kernel pretty well too. For Fedora more recently kernels have been superbly close to upstream for all releases which I am sure must be valued by the user community. Nevertheless I am also clear that archlinux with its rolling release model works and works very well indeed. There have been issues occasionally with Archlinux with things like glibc, and the /usr move but the vast majority of users have survived with a combination of clear announcement guides as well as good wiki entries plus mailing list discussions to help with individual cases which may have been slightly unusual use cases - such as one user who had not updated at all for many many months and then did a huge update which included several key upgrades where an interaction between the order of manual interventions made things a little messy. So my personal experience of arch has been a very positive one - there are differences - for example in arch selinux is not centrally supported - whereas Fedora has been a prime developer for selinux and the vital policy packages that go with it and included as default for several releases. However the ease of maintenance means that for the machines I run with arch make life easier for me, and with careful config settings I have not come up against a security problem. Everyone has a free choice. Arch has also recently moved to systemd as its default init system which was in fact a reasonably simple process to convert to from initscripts - (it took about 10 minutes once you had read the documentation!) - the advantage for arch users is that systemd is the latest upstream or pretty close to - whereas systemd for F16 is somewhat behind current upstream. I guess that there is likely to always be a split in opinion of the developers whenever there is a major fork in philosophy options possible for which way to go in the future - but in the end one way or another a decision must be taken when everyone's views have been considered - for an established distribution there is often inertia against change - and many will see the change as needing more work than people feel may be possible - nevertheless in this case demonstrably archlinux works - so it is certainly possible to have a rolling release model and it already exists.It is simply a philosophy choice as to which model to work with. As to whether Fedora would wish to change or not is entirely up to those who do the hard work writing code and keeping all the tools and packages in working order. So such discussions as in this thread are important - and at the end of the day people doing the developing need to be on board with the philosophy of the distribution or work where they feel comfortable. There have been long discussions previously and at that time the consensus was to keep the status quo - I guess people will continue to
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : I'd rather see us do a better job with rawhide so that more people use it and a better job at making upgrades go smoother so that people just trying to get stuff done with Fedora have a better experience. Then the question is Why people do not use rawhide, and how can we fix the issue so people use it. Maybe that's just perception, maybe there is real recurrent issue to fix one way or another. I do not run it, so I cannot judge, but I think the first step to fix something is to know the exact problems to fix. If the issue is too much breakage, how can we ensure the most annoying issues are prevented ( I am pretty confident in autoQA personnaly ) ? And also, if rawhide start to be more used, we should ensure if doesn't divde the community in 2 groups ( as I have seen some people complain on others distributions that stable release are neglected because devs run $dev_distro and not the stable release ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 00:26 +0100, Michael Scherer wrote: Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : I'd rather see us do a better job with rawhide so that more people use it and a better job at making upgrades go smoother so that people just trying to get stuff done with Fedora have a better experience. Then the question is Why people do not use rawhide, and how can we fix the issue so people use it. Maybe that's just perception, maybe there is real recurrent issue to fix one way or another. I do not run it, so I cannot judge, but I think the first step to fix something is to know the exact problems to fix. If the issue is too much breakage, how can we ensure the most annoying issues are prevented ( I am pretty confident in autoQA personnaly ) ? We have on our todo list to 'enforce' the existing autoqa tests, for depcheck and upgrade path, but we're a little short on people ATM and everyone keeps getting roped into validation testing. I think enforcing depcheck for Rawhide would be going a bit far, though, because then you'd have to use a side tag to do soname bumps, so we kind of have a problem there: we can't blindly reject dependency-breaking changes to Rawhide, but that's the kind of thing that usually causes problems in Rawhide... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Adam Williamson awill...@redhat.com wrote: On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: The guys behind openSUSE created a good approach with Tumbleweed. By adding this repo users can opt-in to the (semi)rolling model. Tumbleweed is more like a pool where updated, stable, non disruptive software can be installed and I was able to talk to the guy who created Tumbleweed some time ago. He said that it is easy to maintain and takes only a few minutes a day to check things. It is difficult, for example, to understand why we have to wait until the next release to have LibreOffice 3.6, since this seems an non disruptive update that could bring major improvements in the productivity of users who rely on office suites to work. I don't think that *adding* tracks is an approach that is going to solve any of our problems, though it might add convenience for a small set of users. We need to be making things simpler, not more complex. :) And in many cases it's simpler to have security updates for an LTS Fedora version than upgrading X workstations every 6 or 12 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, 2012-11-04 at 02:12 +0200, Nikos Roussos wrote: Adam Williamson awill...@redhat.com wrote: On Sat, 2012-11-03 at 09:37 -0200, Henrique Junior wrote: The guys behind openSUSE created a good approach with Tumbleweed. By adding this repo users can opt-in to the (semi)rolling model. Tumbleweed is more like a pool where updated, stable, non disruptive software can be installed and I was able to talk to the guy who created Tumbleweed some time ago. He said that it is easy to maintain and takes only a few minutes a day to check things. It is difficult, for example, to understand why we have to wait until the next release to have LibreOffice 3.6, since this seems an non disruptive update that could bring major improvements in the productivity of users who rely on office suites to work. I don't think that *adding* tracks is an approach that is going to solve any of our problems, though it might add convenience for a small set of users. We need to be making things simpler, not more complex. :) And in many cases it's simpler to have security updates for an LTS Fedora version than upgrading X workstations every 6 or 12 months. I meant 'simpler for developers', not 'simpler for users'. This is, after all, the developer list :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sun, Nov 04, 2012 at 00:26:08 +0100, Michael Scherer m...@zarb.org wrote: Le samedi 03 novembre 2012 à 07:46 -0500, Bruno Wolff III a écrit : I do not run it, so I cannot judge, but I think the first step to fix something is to know the exact problems to fix. If the issue is too much breakage, how can we ensure the most annoying issues are prevented ( I am pretty confident in autoQA personnaly ) ? Well one issue is packagers not doing rawhide builds. This has two issues. One is that rawhide doesn't pick up fixes in updates-testing so doesn't get the latest updates. The other is that the packages aren't built against rawhide libraries which can cause breakage when libraries change. And also, if rawhide start to be more used, we should ensure if doesn't divde the community in 2 groups ( as I have seen some people complain on others distributions that stable release are neglected because devs run $dev_distro and not the stable release ) In Fedora's case the problem is reversed. Rawhide doesn't get enough attention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
I think we could, just for fun if you like, pursue making a good plan of how the transition would be and what changes should be done. Consider it objectively. What changes would have to be done the OS? What changes in infrastructure? What tools do we need? This could be a good exercise. The wiki might be a nice place to do it. How about that? As a sysadmin, I'd love to be able to update to a certain point in time. Like in git, you can just checkout a tag... Wouldn't it be awesome to be able to update to a certain tag? Heh, one could even have spin tags, hehe. Also, having the package manager give you warnings, pointers, suggestions and general messages would rock. I'm just sayin' ;) -- Renich Bon Ciric ren...@woralelandia.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Well your point basically is we can't/don't ship anything that is stable so we should give up on that. I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. Compare it to always cutting edge like rawhide ... you can't get any work done with that. It keeps breaking almost every second day. So things aren't perfect now they aren't as bad as you paint them to be. The current anaconda mess is just a project management failure ... nothing else really. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: Well your point basically is we can't/don't ship anything that is stable so we should give up on that. More or less, yes. I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Who like shiny cutting-edge stuff and don't mind dealing with wonkiness constantly. I wouldn't dream of putting any regular person on a Fedora install, quite frankly. It's easy to get into a perspective bubble where Fedora looks normal, but it isn't. It is not a stable general-purpose operating system and it's absurd to represent it as such. I wouldn't put Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is just your hackneyed old 'regular person' example) and say 'there's your computer'. How many of us would? Even if you get a good Fedora release and don't hit problems with updates - which we don't do a _bad_ job of these days, admittedly - our releases really aren't quality general purpose OSes (we let all kinds of weirdnesses go into our releases which a serious user-facing OS would never let go), and after 12 months, you have to do an upgrade, which has about a 50/50 chance of exploding, let's face it. That's not a convincing stable general purpose operating system. It's telling that when you meet 'normal people' who are running Fedora, they're usually using Fedora N-5, which hasn't had security updates for a year and a half. That's how 'normal people' use their computers - they don't upgrade every year and find it _fun_ to fix the upgrade process when it explodes. I don't think we're serving the (few) 'normal people' who run Fedora in this fashion very well, frankly. They'd probably be better off with something else. I realize my point of view here is somewhat radical, but you need the lunatic fringe around to keep people on their toes, I've always thought. ;) Compare it to always cutting edge like rawhide ... you can't get any work done with that. It keeps breaking almost every second day. Well, that's why I said two streams. One would be what Rawhide is now and the other would be pretty much branched/stable level. On a broad conceptual level - there's several ways of doing this, of course. But my basic point is that the three stream idea works for a project like Debian, which has a conservative approach to everything and is able, over a very long timeframe, to produce something that actually *is* a stable operating system. It's not appropriate to a project like Fedora, which really isn't doing that. How often have we said we don't have the people interested in doing LTS releases, for instance? That's the kind of work you need to maintain a true 'stable' tier in a three-tier system. It's boring maintenance of long-dead code, and that's not generally what Fedora people are interested in. How many maintainers right now are doing a convincing job of maintaining F16? How many people are testing the updates? How many Fedora packagers wake up in the morning and think 'hey, what I really want to do today is carefully test and backport specific fixes to the F16 branches of my packages'? So things aren't perfect now they aren't as bad as you paint them to be. The current anaconda mess is just a project management failure ... nothing else really. The current anaconda mess is an example I used in my post, but it's not the only one. I've been thinking along these lines for a long while, not related to any particular fire. It's a general perspective. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 11/02/2012 07:56 PM, Adam Williamson wrote: Anyway, we've rather torpedo'ed the feature process discussion now, and I'm sorry about that :/. Hence the topic change. But while we're blue sky thinking about massive release process changes, I think it's worth keeping a firm grasp on what Fedora is really about and what it's capable of achieving. I argue that we should have one rolling release which users would be forced to upgrade to every 9 months or so ( following browsers example ) and one stable release ( valid for 2 maybe 3 years ) for those in the community that want something they dont constantly having to upgrade to and can deploy on their servers. ( ofcourse to have a stable release we first and foremost would need maintainers willing to maintain the distribution for that time, epel could maybe be simply dropped for that ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Adam Williamson awill...@redhat.com writes: On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Uh, no. What you describe is usable by the kind of people who use rawhide. Which is what, 1% of our user base? If that. Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. I'm curious what you think package maintainers will do their package maintenance on, if there is no Fedora version that they can trust to still work tomorrow or the day after. (Anyone up for porting fedpkg to Ubuntu?) I've seen a whole lot of user demand for *more* stable versions of Fedora. I've seen none whatever for less stable versions. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 2, 2012 at 10:53 PM, Tom Lane t...@redhat.com wrote: Adam Williamson awill...@redhat.com writes: On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Uh, no. What you describe is usable by the kind of people who use rawhide. Which is what, 1% of our user base? If that. Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. Exactly saves me time to write a reply to Adam's post. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote: Adam Williamson awill...@redhat.com writes: On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Uh, no. What you describe is usable by the kind of people who use rawhide. Which is what, 1% of our user base? If that. Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. I'm curious what you think package maintainers will do their package maintenance on, if there is no Fedora version that they can trust to still work tomorrow or the day after. (Anyone up for porting fedpkg to Ubuntu?) I've seen a whole lot of user demand for *more* stable versions of Fedora. I've seen none whatever for less stable versions. Perhaps I ought to be more clear. I think we can maintain the level of *actual* stability our current 'stable' releases provide with a model such as I describe, while substantially reducing the amount of resources we're wasting at least _theoretically_ maintaining up to four releases at once (currently, 16, 17, 18 and 19). I think there's a lot of heat and not much light going on there. I would envisage that people like you and drago would run the 'stabler' branch in my plan and be happy. The idea isn't to make Fedora less stable than it already is, it's just to be more realistic. I would say that our current process produces the level of stability that you and drago are happy with, but we sometimes act as if it produces a level of stability you could put in a box and sell to people, which it doesn't. If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I disagree with drago's assertion that my description was of people who use Rawhide. It was not intended to be, and it was drawn from the experience of me and other people who do not run Rawhide. I almost never run Rawhide, only Branched. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 02.11.2012 22:53, schrieb Tom Lane: Abandoning any pretense of having stable releases will eliminate a huge fraction of the user community. For sure it will eliminate *me*. I'm not in the business of fighting OS bugs every single day, and I will not be forced into that business. I have other things that I'm more productive at. +1 I'm curious what you think package maintainers will do their package maintenance on, if there is no Fedora version that they can trust to still work tomorrow or the day after. (Anyone up for porting fedpkg to Ubuntu?) +1 I've seen a whole lot of user demand for *more* stable versions of Fedora. I've seen none whatever for less stable versions. +1 Fedora IS USEABLE as a stable base for nearly anything even large upgrades like systemd and UsrMove are working finally they only have too much impact which could be optimized by relax the release-schedules in a direction ok, things are not running like we thought at the begin of the schedule, let us take the time it needs to make stings clean and stable current F18 is a good example POSITIVE: beta delayed multiple times for good reasons NEGATIVE: the promise to hold final release date NO! the right way would be to delay final release to 2013 this would greatly improve the time of testing of a as final declared release where ALL components are having this state at the same time PLEASE: keep in mind this is free software NOT driven by marketing idiots who define release dates - why wasting this real huge benefit for beeing first everytime _ as said: i would propose that one of the two releases each year does not bring large new features with great impact and instead use one schedule to stabilize and fine-polish the distribution at all which maybe save a lot of ressources for upcoming features in the following release signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 02 Nov 2012 15:17:02 -0700 Adam Williamson awill...@redhat.com wrote: ..snip... If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I disagree with drago's assertion that my description was of people who use Rawhide. It was not intended to be, and it was drawn from the experience of me and other people who do not run Rawhide. I almost never run Rawhide, only Branched. Perhaps you have your head too much in the Branched world right now? In my experience, in the last few years, Fedora stable releases have become much more stable. My stable boxes here at home I have not really had to poke at since I upgraded them to Fedora 17. I apply updates every few days and things keep working along fine. In previous cycles there were some real nasty brown paper bag type blowups that required me to do things to downgrade or tweak to keep my stable version working, that (knock on wood) hasn't happened in f16/f17 in my experence. I realize there are bugs and problems that hit, but I think the stable updates policy has helped keep those down. (Cue KevinK to come in and shout and tell me how wrong I am, etc etc) I'm personally -1 to any kind of rolling release beyond rawhide. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Adam Williamson awill...@redhat.com writes: On Fri, 2012-11-02 at 17:53 -0400, Tom Lane wrote: I've seen a whole lot of user demand for *more* stable versions of Fedora. I've seen none whatever for less stable versions. Perhaps I ought to be more clear. I think we can maintain the level of *actual* stability our current 'stable' releases provide with a model such as I describe, while substantially reducing the amount of resources we're wasting at least _theoretically_ maintaining up to four releases at once (currently, 16, 17, 18 and 19). Well, maybe, but yeah you weren't very clear about that. In any case, I'm not seeing how we handle things like library ABI breaks with a rolling release model ... at least not without more work, rather than less, than we have now. If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I don't buy that really. I hit very few bugs in Fedora -- fewer than in OS X for instance. Possibly this is because I use it as a headless server as much as possible, and thus avoid bugs in the desktop-related code. As a development platform it's remarkably stable. (Now admittedly, I never run rawhide, and generally wait till a month after official release before updating my main workstation to a new Fedora version. But with those simple precautions, it is very stable.) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, Nov 2, 2012 at 6:17 PM, Adam Williamson awill...@redhat.com wrote: If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I disagree with drago's assertion that my description was of people who use Rawhide. It was not intended to be, and it was drawn from the experience of me and other people who do not run Rawhide. I almost never run Rawhide, only Branched. Really? I don't remember the last time I had some kind of breakage in my stable branch machines. Now, in the development branches that's a different story, but that's to be somewhat expected due to the daily churn there. Later, /B -- Brian Pepple bpep...@fedoraproject.org https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 13:22 -0700, Adam Williamson wrote: On Fri, 2012-11-02 at 21:07 +0100, drago01 wrote: Well your point basically is we can't/don't ship anything that is stable so we should give up on that. More or less, yes. I disagree with that. Fedora releases had some small regression introduced via updates from time but is is *very* usable as a stable operating system. I disagree. It's usable by the kind of people who use Fedora. Who like shiny cutting-edge stuff and don't mind dealing with wonkiness constantly. I wouldn't dream of putting any regular person on a Fedora install, quite frankly. I do not know in what dreamland you live. My wife has been running on Fedora since forever, and except some pain points when we do an upgrade (usually every 2 release) all works just fine. If you are advocating for making fedora completely unusable please let me know in advance so I can start doing my Red Hat work on some other Linux distro ... I am sure you can read the irony ... It's easy to get into a perspective bubble where Fedora looks normal, but it isn't. It is not a stable general-purpose operating system and it's absurd to represent it as such. I wouldn't put Fedora 17 on my uncle Bob's computer (I don't have an uncle Bob, this is just your hackneyed old 'regular person' example) and say 'there's your computer'. How many of us would? Even if you get a good Fedora release and don't hit problems with updates - which we don't do a _bad_ job of these days, admittedly - our releases really aren't quality general purpose OSes (we let all kinds of weirdnesses go into our releases which a serious user-facing OS would never let go), and after 12 months, you have to do an upgrade, which has about a 50/50 chance of exploding, let's face it. That's not a convincing stable general purpose operating system. It's telling that when you meet 'normal people' who are running Fedora, they're usually using Fedora N-5, which hasn't had security updates for a year and a half. That's how 'normal people' use their computers - they don't upgrade every year and find it _fun_ to fix the upgrade process when it explodes. I don't think we're serving the (few) 'normal people' who run Fedora in this fashion very well, frankly. They'd probably be better off with something else. No normal people run on N-1/N-2 and feel the pain points when they switch to (a month or 2 old) N once N-2 goes out I realize my point of view here is somewhat radical, but you need the lunatic fringe around to keep people on their toes, I've always thought. ;) I understand you surfing hyperbole here, but keep in mind that no users means no developers. Yes some people like to play with all cutting edge, but most people want to use their distro too. If it is too painful to stabilize every 6 months, may be we should change to a rolling release for development, and cut stables only once a year, to be maintained for 1 year only, I would totally love something like that as long as the development version is more something like debian testing/experimental than our current rawhide. Compare it to always cutting edge like rawhide ... you can't get any work done with that. It keeps breaking almost every second day. Well, that's why I said two streams. One would be what Rawhide is now and the other would be pretty much branched/stable level. rawhide would need to get a little bit more stable to be usable even by developers in this scheme, doesn't need to be perfect but you can;t have upgrades that break booting for most people (corner cases always exist it's development). Currently there is ton of stuff that doesn't even build until late in the release cycle. On a broad conceptual level - there's several ways of doing this, of course. But my basic point is that the three stream idea works for a project like Debian, which has a conservative approach to everything and is able, over a very long timeframe, to produce something that actually *is* a stable operating system. It's not appropriate to a project like Fedora, which really isn't doing that. How often have we said we don't have the people interested in doing LTS releases, for instance? That's the kind of work you need to maintain a true 'stable' tier in a three-tier system. It's boring maintenance of long-dead code, and that's not generally what Fedora people are interested in. How many maintainers right now are doing a convincing job of maintaining F16? How many people are testing the updates? How many Fedora packagers wake up in the morning and think 'hey, what I really want to do today is carefully test and backport specific fixes to the F16 branches of my packages'? Yes this is too much, but we *do* get updates for critical issues, and not necessarily in form of a rebase. If we cut the maintenance to one release (instead of the 2 we have now) and switch development to a rolling release that is usable I agree with you we can
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote: On Fri, 02 Nov 2012 15:17:02 -0700 Adam Williamson awill...@redhat.com wrote: ..snip... If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I disagree with drago's assertion that my description was of people who use Rawhide. It was not intended to be, and it was drawn from the experience of me and other people who do not run Rawhide. I almost never run Rawhide, only Branched. Perhaps you have your head too much in the Branched world right now? Not really. I think I have my head more in the 'real' world than some Fedora folks do though ;) I usually run Branched on my desktop and current stable (F-N) on my laptop. How stable is that? Well, the sound on my laptop broke with F17. For several months. It only got fixed because I took the bug upstream and then ensured the fix got ported down into Fedora...that's the experience that *someone who knows how to get people to fix his bugs* has with our product. Imagine the experience a normal person has. In my experience, in the last few years, Fedora stable releases have become much more stable. My stable boxes here at home I have not really had to poke at since I upgraded them to Fedora 17. I apply updates every few days and things keep working along fine. In previous cycles there were some real nasty brown paper bag type blowups that required me to do things to downgrade or tweak to keep my stable version working, that (knock on wood) hasn't happened in f16/f17 in my experence. I realize there are bugs and problems that hit, but I think the stable updates policy has helped keep those down. (Cue KevinK to come in and shout and tell me how wrong I am, etc etc) Sure, like I said in another mail, we've got better at that than before. But as I also said in the same mail, you still have to do a version upgrade every twelve months. That alone is ridiculous for a 'stable' operating system. I don't think we destabilize things - in the sense of 'you update and your machine stops working' very often within a single one of our stable releases. That isn't my point, really. My points are more: * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS * We do not insist on a level of polish or lack of functional regression in our stable releases which is any way consistent with a true productized general purpose OS I'm as well placed as anyone to know _exactly_ what we as a project are happy with signing off on as a final release, and based on my experience working on, using, and doing user support for various distributions and operating systems, I'm happy to maintain that that level is nowhere near a level suitable for a general-purpose stable OS. Our standard for a final release is, broadly, that the installer works pretty well, there are no giant booboos on the desktop, and you can run the updater. We don't care if a feature that was introduced in the previous release is completely broken, unless it affects the critical path, we just say 'fix it with an update'. We don't hold releases for cosmetic bugs, even really obvious ones. We don't hold releases for usability issues. These are all things that serious grown-up operating systems do. That's fine. My posts have a general negative tone just based on the way I'm constructing my argument, but it's important to realize I don't think this is a _problem_. I think what we achieve is roughly what many people who run Fedora want. But we _only_ achieve that level, and we really don't need this unwieldy system of maintaining four releases at a time to achieve it. My fundamental argument is there's a bit of a disconnect between our release process - which is sort of aping the way a stable general-purpose OS would be released, but on fast-forward and with far fewer resources - and our actual goals for the project and the standards we really enforce. We don't _need_ the heavy, constant release cycle we currently employ in order to deliver the good things we already currently deliver. Anyway, I think the point is mashed into the ground by now, so I'll stop. My proposal is more about trying to get people thinking at a fundamental level than it is necessarily something I actually expect the project to adopt wholesale - I just want to make the point that, in designing whatever changes we may make to our processes, we should keep a realistic view of what Fedora is actually _for_, and not over-engineer things. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson awill...@redhat.com wrote: [...] * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS I am not sure why you call it unreliable ... I *never* reinstall unless I really had to (moving one installation from i386 to x86_64). Otherwise I always upgrade using either anaconda back in the days and then preupgrade. There is some weird attitude that upgrades don't work anyway people should just reinstall. Not only is a reinstall a lot more work it is just not something you could ask from a user to do every 6-12 months. Technically there is no difference between an upgrade and package updates just the package set is larger, it just makes dealing with stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks the whole system it will regardless whether you upgrade from FN-1 to FN or doing a yum update in a rolling release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote: My fundamental argument is there's a bit of a disconnect between our release process - which is sort of aping the way a stable general-purpose OS would be released, but on fast-forward and with far fewer resources - and our actual goals for the project and the standards we really enforce. We don't _need_ the heavy, constant release cycle we currently employ in order to deliver the good things we already currently deliver. Sorry, couldn't resist one more note on this; again with the emphasis on 'big picture' and 'historical perspective' that I like, I think it's interesting to consider that the development schedule we use at present is still more or less what Red Hat Linux was using, what, a decade ago? I've been using Linux since around that time - 2000/2001 - and the 'six month stable release cycle' was the norm even _then_. Yet back then 'Linux' was a far smaller world than it is now and far more static. In recent releases the level of change has been, put into perspective, frenetic. We seem to do massive rewrites on one fundamental chunk of infrastructure after another. udev was considered a massive change back in the day, which distros took years to adjust to; now we seem to toss out bits of the bedrock on a weekly basis (hyperbole again, I know). We seem to have been rewriting the whole cluster of systemd+udev +udisks/DeviceKit+PolicyKit+dracut+plymouth+ConsoleKit - that whole ball of wax - more or less constantly for several years (you may notice two of the components in that list have been introduced and thrown away within that space of time...one of them has been obsoleted *twice*), the churn in that stack is crazy. We re-wrote the installer's storage code, stopped for twenty seconds to take a breath, then introduced a new bootloader and switched to GPT disk labels at the same time for an encore. Now we're rewriting the entire installer UI...and we're planning to switch to a revolutionary new filesystem whose userspace implications have barely been mapped out...for the next release (I know this isn't an official plan yet, but it's the stated intention of the btrfs devs). We did the big change to kernel modesetting for graphics drivers. We introduced PulseAudio. GNOME 3 and KDE 4 showed up. In the meantime we've written and introduced an entire virtualization stack into the distro, and added all kinds of other ambitious new features. And I'm sure I'm not even scratching the surface. It kind of feels like for the last five years we've been rewriting more or less the entire distribution from top to bottom every few months (and this applies outside of Fedora, albeit to a lesser extent, as well). It could be memory playing tricks on me, but I'm pretty sure we didn't have anything like that churn rate back when the six month release cycle became the de facto 'industry standard' a decade or more ago. This doesn't necessarily link into the 'rolling release model' argument at all, it just seemed like an interesting perspective to keep in mind in relation to the overall questions we're looking at here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Fri, 2012-11-02 at 16:04 -0700, Adam Williamson wrote: On Fri, 2012-11-02 at 16:31 -0600, Kevin Fenzi wrote: On Fri, 02 Nov 2012 15:17:02 -0700 Adam Williamson awill...@redhat.com wrote: ..snip... If you're using a Fedora release today you're _already_ fighting OS bugs more often than most people do, I'd say. I disagree with drago's assertion that my description was of people who use Rawhide. It was not intended to be, and it was drawn from the experience of me and other people who do not run Rawhide. I almost never run Rawhide, only Branched. Perhaps you have your head too much in the Branched world right now? Not really. I think I have my head more in the 'real' world than some Fedora folks do though ;) I usually run Branched on my desktop and current stable (F-N) on my laptop. How stable is that? Well, the sound on my laptop broke with F17. For several months. It only got fixed because I took the bug upstream and then ensured the fix got ported down into Fedora...that's the experience that *someone who knows how to get people to fix his bugs* has with our product. Imagine the experience a normal person has. Some time it is a bit painful, but on average it's ok, I've seen the same kind of issues on any OS, imagine how nice it is to report a bug like that to Microsoft or Apple ... in most cases you get back a: ask your sound cared/laptop retailer ... and they will blame their OEM and ... if you are lucky they already solved it otherwise tough luck. Sure, like I said in another mail, we've got better at that than before. But as I also said in the same mail, you still have to do a version upgrade every twelve months. That alone is ridiculous for a 'stable' operating system. I don't think we destabilize things - in the sense of 'you update and your machine stops working' very often within a single one of our stable releases. That isn't my point, really. My points are more: I think you are confusing stable with LTS. Stable means upgrade won't break what works, it doesn't mean that we will fix all the known bugs and it also doesn't mean we maintain it forever. It does mean that it would be nice if upgrades were relatively smooth and just plain possible. And if you use a rolling developer model where upgrades *must* be graceful, then you should get that for free, however you will need to do a little bit more work to put stuff in development, just dumping the latest upstream master tree snapshot and hoping it works won't cut it. At the very least you need to do a smoke test upgrading from the previous one. * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS On some stable OSs you cannot upgrade *at all*. It is true that some OSs are maintained for longer time. A short release cycle puts a lot more emphasis on working updates, but to be honest I haven't had huge issues with Fedora, no more than I used to with debian/ubuntu There are some cases were it went south on some releases and I had to manually handle it. But then if that's a problem we could simply create a /home partition by default and users can choose to reinstall just the OS and keep the /home intact. For a desktop that should be ok in all cases where you fear an upgrade would be too dangerous. * We do not insist on a level of polish or lack of functional regression in our stable releases which is any way consistent with a true productized general purpose OS Maybe if we cut stable releases to 1 we can improve this ? The only real reason we maintain N-2 is that forcing a 6mo update on everyone is just ridiculous, but a 1y cycle seems reasonable enough, and with a rolling devel release there would be less reason for frequent stable releases. I'm as well placed as anyone to know _exactly_ what we as a project are happy with signing off on as a final release, and based on my experience working on, using, and doing user support for various distributions and operating systems, I'm happy to maintain that that level is nowhere near a level suitable for a general-purpose stable OS. Our standard for a final release is, broadly, that the installer works pretty well, there are no giant booboos on the desktop, and you can run the updater. We don't care if a feature that was introduced in the previous release is completely broken, unless it affects the critical path, we just say 'fix it with an update'. We don't hold releases for cosmetic bugs, even really obvious ones. We don't hold releases for usability issues. These are all things that serious grown-up operating systems do. I think this is ok, and also the reason why most people wait a month after GA, it is usually fixed by then because *finally* developers moved on the new stable release, discovered all the bigger issues, and fixed them. It means that stable isn't really stable enough for less technical users until 1mo after release but that is ok IMO.
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote: On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson awill...@redhat.com wrote: [...] * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS I am not sure why you call it unreliable ... I *never* reinstall Because I read the forums =) It's not usually terribly unreliable for me either. But I'm a smart cookie like you. I update my systems with yum and I know what I have to do to make it work properly - I follow the instructions and I know how to wiggle my way around dependency issues. This is second nature to me as I'm sure it is to you. You've probably dealt with bugs on upgrades before that you've forgotten about, even. Also, I don't use third party repositories. Normal people do. Especially with a distro like Fedora which doesn't ship Flash, proprietary drivers, Chrome... I've been hanging around user forums for Mandriva, Fedora and Ubuntu for a decade now and I can tell you, every time a new release of any of those comes out, the forums get a big dump of people with problems upgrading. Regular as clockwork. has always happened, more or less will always happen. operating system upgrades are an insoluble problem, really. The number of variables involved in one is astronomical. Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems, both of which have exponentially more testing done on them, much lower levels of churn, and much smaller sets of packages. (Also note how much trouble phone companies have updating Android.) I also know what we do to test upgrades before we sign off on a release, which is 'do a clean install of F-N in a VM and check it can be upgraded to F-N+1'. If that passes, we ship. That is not a level of testing which allows me to declare with confidence that our upgrade process is solid and reliable ;) unless I really had to (moving one installation from i386 to x86_64). Otherwise I always upgrade using either anaconda back in the days and then preupgrade. There is some weird attitude that upgrades don't work anyway people should just reinstall. Not only is a reinstall a lot more work it is just not something you could ask from a user to do every 6-12 months. Technically there is no difference between an upgrade and package updates just the package set is larger, it just makes dealing with stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks the whole system it will regardless whether you upgrade from FN-1 to FN or doing a yum update in a rolling release. Well, kinda. The advantage of a rolling release is that it tends to narrow the focus. You don't have a million people hitting five hundred potentially destabilizing updates all at once; you have a million people all getting one potentially destabilizing update at a time (or, at least, a fairly small set at a time). When everyone starts yelling, you can just look at what got updated the night before and probably find the culprit. That's what happens with Rawhide, after all. And anyway, I don't think a rolling release would be *better* from this point of view - as with my other points, I think a rolling release would allow us to do *just as well* while reducing our testing and development overheads. In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then a week later they deal with bar-1.0 to bar-2.0, then a week later they deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, everyone gets to deal with foo, bar, monkeys and five hundred other changes all at once. Which is chaos on a stick. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote: On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson awill...@redhat.com wrote: [...] * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS I am not sure why you call it unreliable ... I *never* reinstall unless I really had to (moving one installation from i386 to x86_64). On one machine I did upgrade from i386 - x86_64 just for fun. Sure I had to drop in single user 3-4 times and manually install some rpm but eventually I got it done (it was a VM ;) Otherwise I always upgrade using either anaconda back in the days and then preupgrade. There is some weird attitude that upgrades don't work anyway people should just reinstall. Not only is a reinstall a lot more work it is just not something you could ask from a user to do every 6-12 months. it would be nice to squash 2 release cycles and use the gained time to make a better upgrade process imo. Technically there is no difference between an upgrade and package updates just the package set is larger, it just makes dealing with stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks the whole system it will regardless whether you upgrade from FN-1 to FN or doing a yum update in a rolling release. +1 however there is a difference, sometime many little changes over time can run much smoother than one big change at once where you go tfrom pkg release N-10 to N Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Just take a look at this - MS rocks here http://www.youtube.com/watch?v=vPnehDhGa14 -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, Nov 3, 2012 at 12:32 AM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote: On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson awill...@redhat.com wrote: [...] * Upgrading every year, with an unreliable upgrade process, is not something you have to do with a proper stable OS I am not sure why you call it unreliable ... I *never* reinstall Because I read the forums =) It's not usually terribly unreliable for me either. But I'm a smart cookie like you. I update my systems with yum and I know what I have to do to make it work properly - I follow the instructions and I know how to wiggle my way around dependency issues. This is second nature to me as I'm sure it is to you. You've probably dealt with bugs on upgrades before that you've forgotten about, even. Also, I don't use third party repositories. Normal people do. Especially with a distro like Fedora which doesn't ship Flash, proprietary drivers, Chrome... I've been hanging around user forums for Mandriva, Fedora and Ubuntu for a decade now and I can tell you, every time a new release of any of those comes out, the forums get a big dump of people with problems upgrading. What kind of problems? I did upgrade and now my sound card does not work? or actually problems with the upgrade itself? The former would just have happened with a reinstall as well. The number of variables involved in one is astronomical. Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems, Microsoft does. They do even sell upgrade boxes ... much lower levels of churn, No they actually have way higher levels of churn ... just think about it ... in fedora we are talking about 6 months worth of chrun not 5+ years. Can't speak for Red Hat but maybe this is one of the reasons why they don't support upgrades. (Also note how much trouble phone companies have updating Android.) That has more to do with how bad forking is for maintenance ... we don't really have this problem in fedora (ubuntu is driving themselves into this corner but that's OT). I also know what we do to test upgrades before we sign off on a release, which is 'do a clean install of F-N in a VM and check it can be upgraded to F-N+1'. If that passes, we ship. That is not a level of testing which allows me to declare with confidence that our upgrade process is solid and reliable ;) Well it means that the process works. Everything else are bugs in the packages itself which you would have hit during a normal yum update otherwise. unless I really had to (moving one installation from i386 to x86_64). Otherwise I always upgrade using either anaconda back in the days and then preupgrade. There is some weird attitude that upgrades don't work anyway people should just reinstall. Not only is a reinstall a lot more work it is just not something you could ask from a user to do every 6-12 months. Technically there is no difference between an upgrade and package updates just the package set is larger, it just makes dealing with stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks the whole system it will regardless whether you upgrade from FN-1 to FN or doing a yum update in a rolling release. Well, kinda. The advantage of a rolling release is that it tends to narrow the focus. You don't have a million people hitting five hundred potentially destabilizing updates all at once; you have a million people all getting one potentially destabilizing update at a time (or, at least, a fairly small set at a time). When everyone starts yelling, you can just look at what got updated the night before and probably find the culprit. That's what happens with Rawhide, after all. And anyway, I don't think a rolling release would be *better* from this point of view - as with my other points, I think a rolling release would allow us to do *just as well* while reducing our testing and development overheads. In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then a week later they deal with bar-1.0 to bar-2.0, then a week later they deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, everyone gets to deal with foo, bar, monkeys and five hundred other changes all at once. Which is chaos on a stick. But then you have to deal with this kind of stuff every time you update something. That's not really usable if you want to get work done. While the bigger upgrade leaves only hits you once or twice a year. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 00:44 +0100, drago01 wrote: The number of variables involved in one is astronomical. Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems, Microsoft does. They do even sell upgrade boxes ... Well, it's a bit complicated. They didn't support 'true' upgrades from XP to Win 7, for instance - the 'upgrade' process just did a fresh install and then tried to copy back 'important' stuff like your desktop layout. And if it goes wrong...well you can call tech support and they'll do their best, but you're not getting a refund. And Windows upgrades *do* go wrong. Corporate deployments of Windows, to my knowledge, virtually never rely on the upgrade functionality. much lower levels of churn, No they actually have way higher levels of churn ... just think about it ... in fedora we are talking about 6 months worth of chrun not 5+ years. Can't speak for Red Hat but maybe this is one of the reasons why they don't support upgrades. True, that was a bad point; the average rate of churn is lower but the churn between any two releases is big. (Also note how much trouble phone companies have updating Android.) That has more to do with how bad forking is for maintenance ... we don't really have this problem in fedora (ubuntu is driving themselves into this corner but that's OT). I also know what we do to test upgrades before we sign off on a release, which is 'do a clean install of F-N in a VM and check it can be upgraded to F-N+1'. If that passes, we ship. That is not a level of testing which allows me to declare with confidence that our upgrade process is solid and reliable ;) Well it means that the process works. Everything else are bugs in the packages itself which you would have hit during a normal yum update otherwise. That's an oversimplification. A stock install only has a small part of our *official* package set installed. Any given user's system might have any of the others installed, or any third party repo (including a graphics driver from a third party repo). On some upgrades we reinstall the bootloader or do other disruptive things. And again, I'm not saying we could do upgrades better; the fact that 'it'd be just as bad with yum' is besides the point. My point is that major version upgrades are such an intrinsically unreliable operation that any workflow which requires people to do one once a year has problems. They're not something you can realistically expect people to rely on. Microsoft don't really expect you to upgrade Windows. They expect you to buy a computer with Windows X on it, use it for three years, then throw it away and buy a new computer with Windows Y on it. Red Hat expects something similar for RHEL - they don't expect people to upgrade systems from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS migrations, which usually involve buying new hardware, not upgrading existing systems. This is an implicit acknowledgment that upgrades are just not a great way to do things. I don't think we can realistically expect Fedora to do it massively better. If you're going to do stable releases of your operating system, it just doesn't make a lot of sense to make people upgrade every twelve months. If you're going to have stable releases, you should maintain them long enough that people don't really rely on the upgrade function. That seems to be how the big boys do it. If we can't do that, are the stable releases really achieving much? In a rolling release model, everyone deals with foo-1.0 to foo-2.0, then a week later they deal with bar-1.0 to bar-2.0, then a week later they deal with monkeys-1.0 to monkeys-2.0...in a 'stable' release model, everyone gets to deal with foo, bar, monkeys and five hundred other changes all at once. Which is chaos on a stick. But then you have to deal with this kind of stuff every time you update something. That's not really usable if you want to get work done. While the bigger upgrade leaves only hits you once or twice a year. My position is that the people who use Fedora and the kind of people we really _want_ to use Fedora can cope with it. Remember, I'm not proposing it be as bad as Rawhide; we have the whole Bodhi karma process to work with. I think it's plausible to design a process where people only rarely have trouble with updates, even ones that are theoretically pretty messy; about the same frequency they'd have had trouble with upgrading our stable releases. Remember, I mentioned the kernel team as a model; despite my sound gripe, they seem to be managing pretty well in bumping older releases to newer kernels without causing massive breakage. They do cause some problems...but we get 'some problems' anyway. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On Sat, 2012-11-03 at 01:07 +0100, Reindl Harald wrote: Am 03.11.2012 00:58, schrieb Adam Williamson: Microsoft don't really expect you to upgrade Windows. They expect you to buy a computer with Windows X on it, use it for three years, then throw it away and buy a new computer with Windows Y on it. Red Hat expects something similar for RHEL - they don't expect people to upgrade systems from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS migrations, which usually involve buying new hardware, not upgrading existing systems. This is an implicit acknowledgment that upgrades are just not a great way to do things. I don't think we can realistically expect Fedora to do it massively better. If you're going to do stable releases of your operating system, it just doesn't make a lot of sense to make people upgrade every twelve months. If you're going to have stable releases, you should maintain them long enough that people don't really rely on the upgrade function. That seems to be how the big boys do it. If we can't do that, are the stable releases really achieving much? look below, i prove you the opposite Please keep in mind the overall argument I'm making here. I'm not interested in trivial point-scoring. I have machines that have been upgraded for a long time too. Your mail doesn't really speak to the higher level questions here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
Am 03.11.2012 00:58, schrieb Adam Williamson: Microsoft don't really expect you to upgrade Windows. They expect you to buy a computer with Windows X on it, use it for three years, then throw it away and buy a new computer with Windows Y on it. Red Hat expects something similar for RHEL - they don't expect people to upgrade systems from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS migrations, which usually involve buying new hardware, not upgrading existing systems. This is an implicit acknowledgment that upgrades are just not a great way to do things. I don't think we can realistically expect Fedora to do it massively better. If you're going to do stable releases of your operating system, it just doesn't make a lot of sense to make people upgrade every twelve months. If you're going to have stable releases, you should maintain them long enough that people don't really rely on the upgrade function. That seems to be how the big boys do it. If we can't do that, are the stable releases really achieving much? look below, i prove you the opposite Filesystem created: Mon Aug 18 06:48:05 2008 this is the rootfs, which means it was installed with F9 now it has F17, this machine is from the same golden-master as any other machine in the whole company and there is running any service you can imagine on Fedora in production ANY upgrade was done with yum so NO fedora is not as bad as you thin in upgrades the really important ting it that it does not get worser! YES these are Vmware-guests and that is why UPGRADES becoming more and more important - the times where you plan new hardware and install it with a new OS are gone these days you install the OS on hardware X, buy hardware Y and move the whole setup live to the new hardware, the same i am doing even for physical setups on RAID10 - bouy a new machine, start it with the old disks, maybe re-create the initrd and AFTER that if i find it nice change disk by disk and re-sync the RAID or even stuck on the old disks [root@arrakis:~]$ tune2fs -l /dev/sdb1 tune2fs 1.42.3 (14-May-2012) Filesystem volume name: / Last mounted on: / Filesystem UUID: 918f24a7-bc8e-4da5-8a23-8800d5104421 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg dir_nlink Filesystem flags: signed_directory_hash Default mount options:journal_data_writeback Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 393216 Block count: 1572354 Reserved block count: 15723 Free blocks: 999376 Free inodes: 325103 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 383 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Mon Aug 18 06:48:05 2008 Last mount time: Sun Oct 28 19:00:37 2012 Last write time: Sun Oct 28 19:00:36 2012 Mount count: 18 Maximum mount count: -1 Last checked: Tue Mar 27 00:36:36 2012 Check interval: 31104000 (12 months) Next check after: Thu Mar 21 23:36:36 2013 Lifetime writes: 1119 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Journal inode:8 First orphan inode: 34371 Default directory hash: tea Directory Hash Seed: 1e9d689f-15fe-4c0d-aaba-9d323049c7f4 Journal backup: inode blocks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 2 November 2012 17:36, Michał Piotrowski mkkp...@gmail.com wrote: Hi, 2012/11/3 Adam Williamson awill...@redhat.com: Note that neither Red Hat nor Microsoft actually support major version upgrades for their operating systems Just take a look at this - MS rocks here http://www.youtube.com/watch?v=vPnehDhGa14 Support is an overloaded word. You and Adam are using it differently so it of course it is going to conflict. There is a huge difference from it will work and they will support it. Adam is talking about the fact that if your upgrade breaks you will get 0 support from Microsoft to fix it. That only comes with special platinum contracts where they will come in before hand, make sure that it might work, run it on their own machines first, and the do it for you. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
