Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-11-21 at 14:01 -0600, David Lehman wrote: On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote: On 10/19/2012 10:01 AM, David Lehman wrote: This is the main piece of functionality that's still missing: allocating devices from preexisting VGs. You can create and destroy lvm devices. You can reuse existing LVs, optionally reformatting them. You can encrypt or decrypt them. What you cannot do is allocate new LVs from old VGs. That's sort of the last item on the TODO list. It looks like this is still the case in beta RC1, right? Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. See https://bugzilla.redhat.com/show_bug.cgi?id=860677#c10 David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 10/19/2012 10:01 AM, David Lehman wrote: This is the main piece of functionality that's still missing: allocating devices from preexisting VGs. You can create and destroy lvm devices. You can reuse existing LVs, optionally reformatting them. You can encrypt or decrypt them. What you cannot do is allocate new LVs from old VGs. That's sort of the last item on the TODO list. It looks like this is still the case in beta RC1, right? -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote: On 10/19/2012 10:01 AM, David Lehman wrote: This is the main piece of functionality that's still missing: allocating devices from preexisting VGs. You can create and destroy lvm devices. You can reuse existing LVs, optionally reformatting them. You can encrypt or decrypt them. What you cannot do is allocate new LVs from old VGs. That's sort of the last item on the TODO list. It looks like this is still the case in beta RC1, right? Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 11/21/2012 03:01 PM, David Lehman wrote: snip Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. David I, for one, would be interested. Will the image be usable with RC9? Thanks for all of your hard work!! -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 11/21/2012 02:01 PM, David Lehman wrote: On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote: It looks like this is still the case in beta RC1, right? Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. Please. Thanks! -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- 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, 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/05/2012 09:39 AM, drago01 wrote: On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 31 Oct 2012 10:59:54 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I really do not object to a longer release cycle. I am also open to making feature freeze being 4-6 weeks before Alpha change freeze. The risk we run is people land new features anyway. but we run that today. We always have a run of things late. People need to land changes earlier the bigger the change the earlier it needs to land. Maybe it wont be a popular idea but having feature freeze at previous release time is needed. What I am thinking is: Branch as we do, which opens up development for next release same as we do today, so in the current cycle when we branched off f18, f19 features needed to start landing so all that would be taken for f18 is bug fix and integration fixes. when we release f18 we hit F19 feature freeze. That does not work because we do not have unlimited resources ... you can't expect people to work on F19 features at the same time while they are trying to get F18 ready for release. If/when the real work behind a feature has been done early enough, getting from Fedora alpha to final consists of just a few bugfixes that can only be found with sufficiently large test-audience. That's very different from the way things some things land: known very incomplete work submitted at very last minute, followed by a mad scramble to try and scrape it to somehow acceptable state in time. It's avoidable by simply resisting the urge to slip stuff in on the last minute, the release cycle is short enough that world does not end if you postpone something to the next release. Honestly I don't think that the current issues have anything to do with the schedule but more with the way we handled the anaconda feature. We should just fix that and not try to make random changes all over the place. Basically there should not be any this cannot be reverted (there is no such thing really) features. If it is evident before the feature freeze that a given feature would not be ready in time we have to punt it to the next release PERIOD. No disagreement there - features with no feasible contingency plan should be treated very cautiously and if accepted anyway, should have stricter completeness-requirements and much earlier deadlines than easily reversible things. - 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)))
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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Hi, If/when the real work behind a feature has been done early enough, getting from Fedora alpha to final consists of just a few bugfixes Ah well.. only if everybody else did this so all the dependencies are stable. In which case you just moved the development freeze to earlier date. No improvement.. Basically there should not be any this cannot be reverted (there is no such thing really) features. If it is evident before the feature freeze that a given feature would not be ready in time we have to punt it to the next release PERIOD. Then there will be no possibility of major rewrites ever. Because some changes just take more than few months to execute and supporting a branch with very old (anaconda's GUI first commit in git is from 1999) codebase takes a lot of manpower. And to use drago's words: We do not have unlimited resources. When Gnome decides they are not fixing bugs for Gnome2 and put all resources to fixing Gnome3, you can wait, because most apps still depend on the mostly stable Gnome2 anyway and the bugs are not show stoppers, merely annoyances. When we do this in anaconda, you can't just use the older release, because other components are changing underneath us and the old release will break. So you will write bugs and RFEs for us to fix in the old branch so you meet your release deadline and mostly nobody will be testing the new branch. One release later at the alpha time.. we will get into the same issue of not being ready. We will take the heat whatever model we choose. So we have chosen. When this is done, we will have UI which has sane API and is separated from the other internal components and that will allow us to maintain the installer and firstboot in much better and easier way. Martin -- 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 5 Nov 2012 08:39:54 +0100 drago01 drag...@gmail.com escribió: On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 31 Oct 2012 10:59:54 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I really do not object to a longer release cycle. I am also open to making feature freeze being 4-6 weeks before Alpha change freeze. The risk we run is people land new features anyway. but we run that today. We always have a run of things late. People need to land changes earlier the bigger the change the earlier it needs to land. Maybe it wont be a popular idea but having feature freeze at previous release time is needed. What I am thinking is: Branch as we do, which opens up development for next release same as we do today, so in the current cycle when we branched off f18, f19 features needed to start landing so all that would be taken for f18 is bug fix and integration fixes. when we release f18 we hit F19 feature freeze. That does not work because we do not have unlimited resources ... you can't expect people to work on F19 features at the same time while they are trying to get F18 ready for release. Honestly I don't think that the current issues have anything to do with the schedule but more with the way we handled the anaconda feature. We should just fix that and not try to make random changes all over the place. When you doing the major work earlier the work to get the polish and fix the unforeseen issues is smaller, i don't envisage that it needs more resources just a change in focus and how we do things. Basically there should not be any this cannot be reverted (there is no such thing really) features. If it is evident before the feature freeze that a given feature would not be ready in time we have to punt it to the next release PERIOD. realistically most features cant be reverted easily. and people will do and say anything to not have them reverted. often the work to punt the brokenness is the same as to fix it. the sooner we freeze features the more time we have to fix the fallout. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCYm7QACgkQkSxm47BaWfftyQCguB9b7tonxviCmXo957I2ZCY3 gZcAn0DoZ/bnNmJdyURL0It69dbUSBp6 =V+xv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Hmm, actually I have new proposal. Policy about active/inactive maintainers should be decided only by actual maintainers. In the true meritocracy way - if you don't maintain anything you don't have a say. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Saturday, November 3, 2012 4:47:57 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Am 03.11.2012 15:38, schrieb Emmanuel Seyman: * Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
How does it sound? Really like the right way to build community by excluding people? Think about this more before trying to screw others work? Your feature might mean nothing for someone else if you want to see it happen step in and do your part and don't tell people that there work should be removed. P.S. My words would have been a lot more harsh if sending from personal email!! Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Sunday, November 4, 2012 9:30:49 AM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Hmm, actually I have new proposal. Policy about active/inactive maintainers should be decided only by actual maintainers. In the true meritocracy way - if you don't maintain anything you don't have a say. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Saturday, November 3, 2012 4:47:57 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: howto install into a LVM partitions (or RAID)) Am 03.11.2012 15:38, schrieb Emmanuel Seyman: * Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
nobody here is screwing others work teh topic is how about to find out AUTOMATICALLY which are they doing the work and which things are orphaned without finding it out the hard way in the running release cycle and if you need to find out things automatically you need any flag to measure - this would be FAS login Am 04.11.2012 08:37, schrieb Aleksandar Kurtakov: How does it sound? Really like the right way to build community by excluding people? Think about this more before trying to screw others work? Your feature might mean nothing for someone else if you want to see it happen step in and do your part and don't tell people that there work should be removed. P.S. My words would have been a lot more harsh if sending from personal email!! Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Sunday, November 4, 2012 9:30:49 AM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Hmm, actually I have new proposal. Policy about active/inactive maintainers should be decided only by actual maintainers. In the true meritocracy way - if you don't maintain anything you don't have a say. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Saturday, November 3, 2012 4:47:57 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: howto install into a LVM partitions (or RAID)) Am 03.11.2012 15:38, schrieb Emmanuel Seyman: * Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired 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 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
The point is that such a measurement serves nothing but pissing off people. You need to track activity on packages - how long bugs stay open without response (note that this doesn't mean becoming accepted as one might be busy with other things), how long the package stay with open CVEs, what is the usual delay for getting to latest upstream, etc. Come up with strategy based on such measurement and you'll get packagers support for some automated actions against packages (NOT PEOPLE). Measuring people activity means nothing as I think we want MORE people to work with us not less (even if they do it once in a year). P.S. The words in capital letters are such intentionally. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Sunday, November 4, 2012 12:15:14 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) nobody here is screwing others work teh topic is how about to find out AUTOMATICALLY which are they doing the work and which things are orphaned without finding it out the hard way in the running release cycle and if you need to find out things automatically you need any flag to measure - this would be FAS login Am 04.11.2012 08:37, schrieb Aleksandar Kurtakov: How does it sound? Really like the right way to build community by excluding people? Think about this more before trying to screw others work? Your feature might mean nothing for someone else if you want to see it happen step in and do your part and don't tell people that there work should be removed. P.S. My words would have been a lot more harsh if sending from personal email!! Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Sunday, November 4, 2012 9:30:49 AM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Hmm, actually I have new proposal. Policy about active/inactive maintainers should be decided only by actual maintainers. In the true meritocracy way - if you don't maintain anything you don't have a say. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Saturday, November 3, 2012 4:47:57 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Am 03.11.2012 15:38, schrieb Emmanuel Seyman: * Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a écrit : The point is that such a measurement serves nothing but pissing off people. You need to track activity on packages - how long bugs stay open without response (note that this doesn't mean becoming accepted as one might be busy with other things), how long the package stay with open CVEs, what is the usual delay for getting to latest upstream, etc. Come up with strategy based on such measurement and you'll get packagers support for some automated actions against packages (NOT PEOPLE). Measuring people activity means nothing as I think we want MORE people to work with us not less (even if they do it once in a year). P.S. The words in capital letters are such intentionally. While I agree that this may make lose some contributions, on the other hand, there is some team that have more aggressive pruning ( infrastructure team, for example ). And keeping inactive accounts could cause issue for voting ( ie, if we need for some reason to have a quorum of people ), and for sure could increase the work for various sysadmin tasks in some specific case ( like if we need to contact all users to make them change their password and check they did ). -- 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)))
- 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: 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:32:33 +, Richard W.M. Jones wrote: If you substitute 'unstable' for level 1, 'testing' for level 2 and 'stable' for level 3, then this is not dissimilar to how Debian operates. Sure, and if you eliminate level 3 (which leads to multi-year-long freezes), then you have mostly I would like to see ;) Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 31 Oct 2012 10:59:54 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I really do not object to a longer release cycle. I am also open to making feature freeze being 4-6 weeks before Alpha change freeze. The risk we run is people land new features anyway. but we run that today. We always have a run of things late. People need to land changes earlier the bigger the change the earlier it needs to land. Maybe it wont be a popular idea but having feature freeze at previous release time is needed. What I am thinking is: Branch as we do, which opens up development for next release same as we do today, so in the current cycle when we branched off f18, f19 features needed to start landing so all that would be taken for f18 is bug fix and integration fixes. when we release f18 we hit F19 feature freeze. that then will give us close to 3 months to do most of the integration fixing and stabalising. we then rinse and repeat. It would mean that we need to start making rawhide installable again, though thats something that seems to be inevitable, we could do weekly snapshot test composes. I am willing from the releng side to do the work needed. I think we need to give developers more time for feature integration after the feature freeze. I am all for giving developers more time to integrate with other features. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCXRykACgkQkSxm47BaWfdGrgCgh+nK7OKFhPLSu+VQV9XXTyYb j4kAniud8lfIuGEouw3Ib3yHy4gc8+bK =Zu8Z -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Michael, Without contributors there is no need for infrastructure, right? ;) To me it means that we need more contributors working on infrastructure (as on every other aspect of the distro) not pruning. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Michael Scherer m...@zarb.org To: devel@lists.fedoraproject.org Sent: Sunday, November 4, 2012 9:43:49 PM Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)) Le dimanche 04 novembre 2012 à 13:19 -0500, Aleksandar Kurtakov a écrit : The point is that such a measurement serves nothing but pissing off people. You need to track activity on packages - how long bugs stay open without response (note that this doesn't mean becoming accepted as one might be busy with other things), how long the package stay with open CVEs, what is the usual delay for getting to latest upstream, etc. Come up with strategy based on such measurement and you'll get packagers support for some automated actions against packages (NOT PEOPLE). Measuring people activity means nothing as I think we want MORE people to work with us not less (even if they do it once in a year). P.S. The words in capital letters are such intentionally. While I agree that this may make lose some contributions, on the other hand, there is some team that have more aggressive pruning ( infrastructure team, for example ). And keeping inactive accounts could cause issue for voting ( ie, if we need for some reason to have a quorum of people ), and for sure could increase the work for various sysadmin tasks in some specific case ( like if we need to contact all users to make them change their password and check they did ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: 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:57 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 31 Oct 2012 10:59:54 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I really do not object to a longer release cycle. I am also open to making feature freeze being 4-6 weeks before Alpha change freeze. The risk we run is people land new features anyway. but we run that today. We always have a run of things late. People need to land changes earlier the bigger the change the earlier it needs to land. Maybe it wont be a popular idea but having feature freeze at previous release time is needed. What I am thinking is: Branch as we do, which opens up development for next release same as we do today, so in the current cycle when we branched off f18, f19 features needed to start landing so all that would be taken for f18 is bug fix and integration fixes. when we release f18 we hit F19 feature freeze. That does not work because we do not have unlimited resources ... you can't expect people to work on F19 features at the same time while they are trying to get F18 ready for release. Honestly I don't think that the current issues have anything to do with the schedule but more with the way we handled the anaconda feature. We should just fix that and not try to make random changes all over the place. Basically there should not be any this cannot be reverted (there is no such thing really) features. If it is evident before the feature freeze that a given feature would not be ready in time we have to punt it to the next release PERIOD. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
- Original Message - From: drago01 drag...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, November 5, 2012 9:39:54 AM Subject: 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:57 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 31 Oct 2012 10:59:54 -0700 Jesse Keating jkeat...@j2solutions.net escribió: On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I really do not object to a longer release cycle. I am also open to making feature freeze being 4-6 weeks before Alpha change freeze. The risk we run is people land new features anyway. but we run that today. We always have a run of things late. People need to land changes earlier the bigger the change the earlier it needs to land. Maybe it wont be a popular idea but having feature freeze at previous release time is needed. What I am thinking is: Branch as we do, which opens up development for next release same as we do today, so in the current cycle when we branched off f18, f19 features needed to start landing so all that would be taken for f18 is bug fix and integration fixes. when we release f18 we hit F19 feature freeze. That does not work because we do not have unlimited resources ... you can't expect people to work on F19 features at the same time while they are trying to get F18 ready for release. Honestly I don't think that the current issues have anything to do with the schedule but more with the way we handled the anaconda feature. We should just fix that and not try to make random changes all over the place. Basically there should not be any this cannot be reverted (there is no such thing really) features. If it is evident before the feature freeze that a given feature would not be ready in time we have to punt it to the next release PERIOD. Looks like this issue comes to every project(pretty similar thing happened in Eclipse for 4.x). What happens if Anaconda devs say they can no long maintain the old version and they will spend all their time on the new one? Will there some magic happen and someone else will step in to do the changes in anaconda for the new dracut (mentioned in the thread)? Or we will revert dracut and systemd and etc. to their f17 version making no point in even having new release maybe? I agree we fail but sometimes you can not just revert and the better idea looks like when some such low level changes happen it is better to just accept it and make the release a bit longer from the beginning. Alexander Kurtakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 à 11:19 +0530, Rahul Sundaram a écrit : On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote: well, it would maybe a start to DROP packages which are still missing systemd-units http://fedoraproject.org/wiki/Releases/18/FeatureList 60% SysV to Systemd Dropping 40% of packages isn't going to happen. Sorry Especially since some of those packages may have more complex initscript than a simple systemd unit can produce. For example, on my system, ceph, netcf-transaction or libvirt-guests are more complex initscripts, and I could understand why they were not migrated by now. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/03/2012 08:17 AM, Michael Scherer wrote: Le samedi 03 novembre 2012 à 11:19 +0530, Rahul Sundaram a écrit : On Fri, Nov 2, 2012 at 10:25 PM, Reindl Harald wrote: well, it would maybe a start to DROP packages which are still missing systemd-units http://fedoraproject.org/wiki/Releases/18/FeatureList 60% SysV to Systemd Dropping 40% of packages isn't going to happen. Sorry Especially since some of those packages may have more complex initscript than a simple systemd unit can produce. For example, on my system, ceph, netcf-transaction or libvirt-guests are more complex initscripts, and I could understand why they were not migrated by now. Yeah upstream often is working making some other changes surrounding the unit and the daemon + nobody said or promised this was going to be migrated within one release cycle anyway Reindl Harald just likes to make a fuzz... And people should not be staring to much into the % they do not always accurately reflect the feature completeness... 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)))
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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
* Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused. 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 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Am 03.11.2012 15:38, schrieb Emmanuel Seyman: * Jóhann B. Guðmundsson [02/11/2012 20:34] : That package would hardly be un-maintained if it has co-maintainers now does it... Absolutely. Hence my request that any process we put in place be package-focused rather than maintainer-focused why? how will you do this? if there is nothing to change on a apckage it is at it is if any maintainer not login he is INACTIVE if a package has more maintainers it is no problem retire the inactive maintainer if a package has only one maintainer and he is gone away the package has to be retired 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Quoting Michael Cronenworth (2012-11-01 18:33:24) Adam Williamson wrote: I didn't want to throw this grenade into the debate, but now someone else has, I'll just note that I was in favour of this before and I'm still in favour of it now. :) Rolling release is a model that makes clear sense for a distribution with the goals that Fedora has. I've wanted to write up a blog post about my plan for a rolling release, but I'll post a snip-it here. Fedora Rawhide - stays as is... it is a rolling release Fedora Feature - think of it as F18 beta right now Fedora Stable - think of it as F16/F17 right now People choose the branch level at install time. Of course, like now, people can override this in the future with a change of fedora-release or yum --releasever. However, per-package updates from another branch level might not be something everyone can agree on how to handle, so it might be wise to limit support of it at first. Workflow: A shiny new feature is introduced in Rawhide. Things go boom. Not many people are hurt by this. Once it has been given a few band-aids the feature could be submitted to Fedora Feature. After some hardening and polishing the feature could finally be pushed to Fedora Stable. I feel this should give a good compromise to everyone's fears of a rolling release. It gives the feature freaks a place in Fedora. It gives the stable stubborns a place in Fedora. I'll wake up from my dream now. I recently came up with similar 3-layer idea. My description was a bit different, something like this: 1. level - rawhide-like repository, more or less anything goes 2. level - package moves here after maintainer says this package has been working for me for some time and looks OK. Let's integrate properly with rest of the system. 3. level - packages integrated and experience should be splendid :-) However let's see how we'd handle systemd change with this system: 1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd as worthy FEATURE for future stable (3rd level). Packages interacting with init system can take their time updating. 2. level - systemd moves here. After this point, packages moving from 1st level here, will have to support systemd. Experience will likely be shaky for a time, then settle down. 3. level - after some time (1 year, 2 years?) systemd moves here and all packages that have been fixed to work with it as well There are several problems with this approach though: 1. There are always multiple big changes happening in fedora. So even stable would see big updates on relatively frequent basis. 2. Several big changes will interact with each other. I.e. Gnome update will contain some daemons so they'd have to integrate with systemd on 2nd level. But then Gnome couldn't go into 3rd level before systemd. 3...x. a long list of further problems I am hopeful that we could make this work. Would anyone be willing to do analysis like this for multiple updates and play devil's advocate as well? Ideally trying to see how we could create processes to handle updates of the last 1-2 years? Because all I could come up with is: we'd end up like Debian, where stable is...ancient. Not that that is bad in itself if you can pick. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 1 November 2012 17:33, Michael Cronenworth m...@cchtml.com wrote: Adam Williamson wrote: I didn't want to throw this grenade into the debate, but now someone else has, I'll just note that I was in favour of this before and I'm still in favour of it now. :) Rolling release is a model that makes clear sense for a distribution with the goals that Fedora has. I've wanted to write up a blog post about my plan for a rolling release, but I'll post a snip-it here. Fedora Rawhide - stays as is... it is a rolling release Fedora Feature - think of it as F18 beta right now Fedora Stable - think of it as F16/F17 right now People choose the branch level at install time. Of course, like now, people can override this in the future with a change of fedora-release or yum --releasever. However, per-package updates from another branch level might not be something everyone can agree on how to handle, so it might be wise to limit support of it at first. Workflow: A shiny new feature is introduced in Rawhide. Things go boom. Not many people are hurt by this. Once it has been given a few band-aids the feature could be submitted to Fedora Feature. After some hardening and polishing the feature could finally be pushed to Fedora Stable. How does this work with things like Anaconda? In a rolling model (assuming you can do other major upgrades without reinstalling, if not there's less point anyway), people aren't going to be reinstalling so it could easily trickle through to stable before getting serious use. How does it work with major changes like UsrMove? It might never have been done... -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 10:55 AM, Stanislav Ochotnicky wrote: Quoting Michael Cronenworth (2012-11-01 18:33:24) Adam Williamson wrote: I didn't want to throw this grenade into the debate, but now someone else has, I'll just note that I was in favour of this before and I'm still in favour of it now. :) Rolling release is a model that makes clear sense for a distribution with the goals that Fedora has. I've wanted to write up a blog post about my plan for a rolling release, but I'll post a snip-it here. Fedora Rawhide - stays as is... it is a rolling release Fedora Feature - think of it as F18 beta right now Fedora Stable - think of it as F16/F17 right now People choose the branch level at install time. Of course, like now, people can override this in the future with a change of fedora-release or yum --releasever. However, per-package updates from another branch level might not be something everyone can agree on how to handle, so it might be wise to limit support of it at first. Workflow: A shiny new feature is introduced in Rawhide. Things go boom. Not many people are hurt by this. Once it has been given a few band-aids the feature could be submitted to Fedora Feature. After some hardening and polishing the feature could finally be pushed to Fedora Stable. I feel this should give a good compromise to everyone's fears of a rolling release. It gives the feature freaks a place in Fedora. It gives the stable stubborns a place in Fedora. I'll wake up from my dream now. I recently came up with similar 3-layer idea. My description was a bit different, something like this: 1. level - rawhide-like repository, more or less anything goes 2. level - package moves here after maintainer says this package has been working for me for some time and looks OK. Let's integrate properly with rest of the system. 3. level - packages integrated and experience should be splendid :-) However let's see how we'd handle systemd change with this system: 1. level - Lennart packages systemd, plays around with it. FESCO accepts systemd as worthy FEATURE for future stable (3rd level). Packages interacting with init system can take their time updating. 2. level - systemd moves here. After this point, packages moving from 1st level here, will have to support systemd. Experience will likely be shaky for a time, then settle down. 3. level - after some time (1 year, 2 years?) systemd moves here and all packages that have been fixed to work with it as well There are several problems with this approach though: 1. There are always multiple big changes happening in fedora. So even stable would see big updates on relatively frequent basis. 2. Several big changes will interact with each other. I.e. Gnome update will contain some daemons so they'd have to integrate with systemd on 2nd level. But then Gnome couldn't go into 3rd level before systemd. 3...x. a long list of further problems I am hopeful that we could make this work. Would anyone be willing to do analysis like this for multiple updates and play devil's advocate as well? Ideally trying to see how we could create processes to handle updates of the last 1-2 years? Because all I could come up with is: we'd end up like Debian, where stable is...ancient. Not that that is bad in itself if you can pick. Trust me when I say this we have to fix other processes we have *before* we can properly fix the feature process. Until that is done there is no point in trying to fix the feature process. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 9:03 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Trust me when I say this we have to fix other processes we have *before* we can properly fix the feature process. Which? Until that is done there is no point in trying to fix the feature process. I disagree. While we might not be able to come to a set-in-stone perfect process for Features, we can certainly make incremental improvements to it. It will never be set-in-stone anyway. Perfect is the enemy of good, etc etc. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 11:55:37AM +0100, Stanislav Ochotnicky wrote: I recently came up with similar 3-layer idea. My description was a bit different, something like this: 1. level - rawhide-like repository, more or less anything goes 2. level - package moves here after maintainer says this package has been working for me for some time and looks OK. Let's integrate properly with rest of the system. 3. level - packages integrated and experience should be splendid :-) If you substitute 'unstable' for level 1, 'testing' for level 2 and 'stable' for level 3, then this is not dissimilar to how Debian operates. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Ian Malone wrote: How does this work with things like Anaconda? In a rolling model (assuming you can do other major upgrades without reinstalling, if not there's less point anyway), people aren't going to be reinstalling so it could easily trickle through to stable before getting serious use. Installer images could remain at a 6 month interval, or change to a 12 month interval, or be spun after a major feature reaches one of the branch levels. There is more flexibility in a rolling release model to ship a installer image. The QA group would retain their duties in testing as they do so today. In fact, it might make QA a stronger group as today they can only focus on Rawhide/Branched releases. Very little QA time is spent on N+1 or even N releases. Lacking a version tag doesn't mean things will go untouched. The only way features would advance down a branch level is if they received approval from FESCo/QA. How does it work with major changes like UsrMove? It might never have been done... How does it [something similar] work with Gentoo or Debian? :) In the case of major file system changes, and not just package updates, a distribution upgrade tool (fedup?) would be required. Yum would need to gain the smarts to see distribution updates as well as regular packages. Such a feature existed on my Nokia N900 phone (Debian) to upgrade it to new major releases without reflashing or command-line usage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Stanislav Ochotnicky sochotni...@redhat.com writes: Quoting Michael Cronenworth (2012-11-01 18:33:24) I've wanted to write up a blog post about my plan for a rolling release, but I'll post a snip-it here. I recently came up with similar 3-layer idea. In my little corner of the system, the main thing that causes distro-level issues is new upstream versions of libraries, carrying API/ABI breaks. (Recent examples include the libpng 1.2.x - 1.5.x and libtiff 3.9.x - 4.0.x upgrades.) To push one of those into rawhide, we at least have to rebuild all dependent packages, and typically some of them need source-level patches too. In the current model, once that's been done in rawhide, the problem is over: all those packages will propagate to release branches together. ISTM a rolling release would make this sort of thing enormously more complicated. Almost certainly, not all those packages would be at similar levels of stability and so there would be no point at which they could all get pushed to any stable branch. How would you handle that without creating a huge amount of extra work for packagers? Keep in mind this type of thing happens *constantly*, probably a dozen times per release cycle across the whole distro. Any significant extra burden is going to be insupportable. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 01:20 PM, Josh Boyer wrote: On Fri, Nov 2, 2012 at 9:03 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Trust me when I say this we have to fix other processes we have *before* we can properly fix the feature process. Which? As soon as an feature depends on other components or several other components and their maintainers involvement/participation, then for example the unresponsive maintainers policy conflicts with the feature process given our relatively short development cycle. ( in general the current ownership model works against features that involve more then one component ) Another example cleaning up dead/deprecated packages which ought to happen at the beginning on new development cycle so feature maintainers wont work on dead or unmaintained packages etc... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 02:52:46PM +, Jóhann B. Guðmundsson wrote: As soon as an feature depends on other components or several other components and their maintainers involvement/participation, then for example the unresponsive maintainers policy conflicts with the feature process given our relatively short development cycle. ( in Can you explain that a little more? Do you mean the policy is too slow? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 02:58 PM, Matthew Miller wrote: On Fri, Nov 02, 2012 at 02:52:46PM +, Jóhann B. Guðmundsson wrote: As soon as an feature depends on other components or several other components and their maintainers involvement/participation, then for example the unresponsive maintainers policy conflicts with the feature process given our relatively short development cycle. ( in Can you explain that a little more? Do you mean the policy is too slow? Dead/un-maintained packages need to be removed/reassigned at the very *beginning* of an new development cycle so feature owners and others working in the community are dealing with active and actively maintained packages. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 03:12:56PM +, Jóhann B. Guðmundsson wrote: As soon as an feature depends on other components or several other components and their maintainers involvement/participation, then for example the unresponsive maintainers policy conflicts with the feature process given our relatively short development cycle. ( in Can you explain that a little more? Do you mean the policy is too slow? Dead/un-maintained packages need to be removed/reassigned at the very *beginning* of an new development cycle so feature owners and others working in the community are dealing with active and actively maintained packages. Okay. But I'm having trouble seeing how that's a blocker for incremental improvement to the features process. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 03:32 PM, Matthew Miller wrote: On Fri, Nov 02, 2012 at 03:12:56PM +, Jóhann B. Guðmundsson wrote: As soon as an feature depends on other components or several other components and their maintainers involvement/participation, then for example the unresponsive maintainers policy conflicts with the feature process given our relatively short development cycle. ( in Can you explain that a little more? Do you mean the policy is too slow? Dead/un-maintained packages need to be removed/reassigned at the very *beginning* of an new development cycle so feature owners and others working in the community are dealing with active and actively maintained packages. Okay. But I'm having trouble seeing how that's a blocker for incremental improvement to the features process. It's pretty apparent that there is no point in working with the feature process et all if those issues aren't address first no matter how many incremental improvements you make to the process or when you do it for that matter. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 11/02/2012 03:32 PM, Matthew Miller wrote: On Fri, Nov 02, 2012 at 03:12:56PM +, Jóhann B. Guðmundsson wrote: Dead/un-maintained packages need to be removed/reassigned at the very *beginning* of an new development cycle so feature owners and others working in the community are dealing with active and actively maintained packages. How exactly are you going to force maintainers who go missing to do so at a prescheduled time? Real life is seldom that convenient. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 04:25 PM, Tom Lane wrote: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 11/02/2012 03:32 PM, Matthew Miller wrote: On Fri, Nov 02, 2012 at 03:12:56PM +, Jóhann B. Guðmundsson wrote: Dead/un-maintained packages need to be removed/reassigned at the very *beginning* of an new development cycle so feature owners and others working in the community are dealing with active and actively maintained packages. How exactly are you going to force maintainers who go missing to do so at a prescheduled time? Real life is seldom that convenient. If at this point we dont have any process that can actively tell if a maintainer is present and active within the project then we have bigger fish to fry then the feature process... Seriously it should not be anymore complex than monitoring last login into the relevant infrastructure pieces to determine if the relevant maintainer is active or not. bash script + a cron job should suffice to achieve just that. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 11/02/2012 04:25 PM, Tom Lane wrote: How exactly are you going to force maintainers who go missing to do so at a prescheduled time? Real life is seldom that convenient. bash script + a cron job should suffice to achieve just that. Somehow, we are failing to communicate. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Indeed. If someone owns 4 packages that are all stable and have no bug reports, are they inactive? -J On Fri, Nov 2, 2012 at 11:56 AM, Tom Lane t...@redhat.com wrote: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 11/02/2012 04:25 PM, Tom Lane wrote: How exactly are you going to force maintainers who go missing to do so at a prescheduled time? Real life is seldom that convenient. bash script + a cron job should suffice to achieve just that. Somehow, we are failing to communicate. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 04:56 PM, Tom Lane wrote: How exactly are you going to force maintainers who go missing to do so at a prescheduled time? Real life is seldom that convenient. bash script + a cron job should suffice to achieve just that. Somehow, we are failing to communicate. We would not force them to do anything how could we they are awol and you do realize that process can be automated even if that just generates a list of components that *look* to be unmaintained and then what releng? goes through that list of components and takes the next step to orphan them... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
* Jóhann B. Guðmundsson [02/11/2012 18:59] : If at this point we dont have any process that can actively tell if a maintainer is present and active within the project then we have bigger fish to fry then the feature process... This really does not matter. We've had maintainers that were AWOL for years without this affecting the distribution one bit because their packages were cared for by co-maintainers and the appropriate SIGs. If a package is unmaintained, send out a call to co-maintain to devel@ and open up its ACLs. Seriously it should not be anymore complex than monitoring last login into the relevant infrastructure pieces to determine if the relevant maintainer is active or not. Flagging maintainers as active/inactive is fun but it doesn't actually improve the distribution. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/02/2012 06:56 PM, Emmanuel Seyman wrote: If a package is unmaintained, send out a call to co-maintain to devel@ and open up its ACLs. That package would hardly be un-maintained if it has co-maintainers now does it... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
