Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 06:39 PM, Jesse Keating wrote: On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Yeah, if you pick the line at say critical then every update would have a CVE, or would be bundled in bodhi with the package that had the CVE. So say webkit needs updating due to a CVE, you would bundle all the dependent packages in the same update, and the whole update itself would have the CVE listing, and would have just once announcement. +1, my thoughts exactly. The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? Could go by time it takes to get a CVE discovered/fixed, how many are slipping through, karma on the updates, or just mirrormanager hits on the repos. Agreed, these certainly are measurables. Might be a little harder to get some figures on, but we'd have to figure it out at some point anyway. * A timeline to go with the above to review for success/failure Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called Alpha freeze -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. I would think 6 months might be a little too short. Why not give it a year? 6 months would be what we can commit to now, right now, to extend the life cycle of one Fedora release with. Depending on those results, and it's success, we might be able to 1) extend the life cycle a little more, and/or 2) take on a second release's extended life cycle. * A responsible body behind the effort to make regular reports to FESCo/Board This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. You're driving the feature, but don't want to be responsible for the feature? odd? Yes, I'm driving the feature. That doesn't mean I'm in a position to say anything definitive ;-) I'm not elected, chosen, endorsed, unique in this initiative, or anything else, I'm just driving it. Even if I were to be assigned a leading position within whatever governance body should govern this feature/initiative, I'd not be in control -like I said before though; different subject ;-) If, supposedly, FESCo (or the Board) says hell yeah (or just 'yes', which would do) to the initiative, then I suppose we put our jewels on the table and determine the final shape and form of the project. Who is going to track and discover the security issues? To be determined. Could be delegated to a (dedicated?) small(er) group of people within the SIG (to be set up) -maybe the not-so-technical??, or could be a responsible of each individual participating. Ok, so long as your aware that somebody or somebodies will need to monitor the entire package set for CVEs (something we're probably missing to some extent already). And so this has to be resolved from a Fedora Project wide perspective rather then just be assigned to the people that co-incidentally said security fixes only. This can not and will not ever be a measurable against the ELC feature if the Fedora Project itself does not have the same or similar procedures approved and implemented. If we miss out on a few, or many, then we're bad. If the Fedora Project misses out on just as much, then we're good, within the bad, bad Fedora Project. Even though a Fedora release is much less likely to have security issues linger around for a while due to frequent updates being available for virtually any given application, the Fedora Project sets the standard in this case, not vice-versa ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- John5342 john5...@googlemail.com wrote: Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. If what you said is completely true, I would not even bother to propose Denture. :-) What i said is plain and simple fact. The scenario i mentioned is one of several points of failure. I am not suggesting it is a problem with Denture itself but it is a problem with the real world. Thats just life. But the fact does not cover all packages, so that's why I need Denture, and take the risk. That's also life. :-) This isn't about whether Y-1.3 will be pulled in. If you do what the vast majority of users do then you will get the equivelant of yum update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 will still be updated siply because there is a later version. When you update using Denture however you could easily end up with X-1.3 and Y-1.2 for any number of reasons. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. So do other package managers. Tell me, why are you so sure that the current version packages don't break the system secretly and user and the package managers has no way of knowing until it is too late? If you read all i wrote then you will find that has been answered thoroughly already. I also states my justification why the packages should specify the exact depended versions. You have found the exceptions there. Try looking at some others. I see. What I mainly need Denture help is for end-user applications. I am not quite sure about using Denture for library or toolkit directly. I am sure even your dependency versions become stale. Taking your example of dvdauthor BuildRequires: libpng-devel BuildRequires: flex BuildRequires: bison BuildRequires: fribidi-devel BuildRequires: freetype-devel BuildRequires: GraphicsMagick-devel BuildRequires: autoconf automake gettext-devel In a single release you perhaps can be pretty sure that the versions in the build root are good enough to satisfy dvdauthor. If on the other hand you end up with a version of one of these packages from a previous release due to blacklisting then things may well start to break. Would you however insist that all of these are bugs? Mmm, BuildRequires: libdvdread-devel = 0.9.4-4 BuildRequires: libxml2-devel = 2.6.0 Without these, dvdauthor might break even within current release. You were saying that version is not important? :-) Nevertheless, you raise a valid point that version information is sometime unavailable or unreliable. But this can be overcome by a datafile that stores correct version. The result could be great but i can be pretty sure that the actually stability of a partially updated system is probably much worse than rawhide and people who are happy with that level of stability would ore than likely just prefer actual recent release For people who requires absolute stable, they can just use CentOS/ RHEL and totally ignore Denture. Denture is for the people that need to keep some critical packages, but wouldn't mind to take some risk. :-) I like the idea because the concept is great. The idea that you can run whatever version of whatever package you want and get the best of all worlds is a nice dream but unfortunately i also know that it is only a dream and in real life it simply can't work because the huge requirements that Denture would place on packaging just can't be done. Whatever is possibly the problem. Denture only eats what it can eat. :-) According to my experience, some of the dreams can come true. When i was working on my project i quickly realised that for the reasons i have been trying to explain (falling on deaf ears apparently). Please don't assume that I am not aware your concerns. Did you see my answers about them? I really wish you all the best. I really do. I would love to be surprised and see it work but i won't be holding my breath. Good luck! Thanks! -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- John5342 john5...@googlemail.com wrote: 2009/7/8 Ding Yi Chen dc...@redhat.com: I don't think this has anything to do with motivation. You have an idea and on the face of it it sounds great but even the greatest ideas can be doomed by the details. If you don't believe me (or Kevin) then go for it and when you get to the details you will see exactly what we are talking about. We are simply trying to save you the time. You have good deed. But it does not help by simply saying everything break. As I do have some example to break your claim. :-) I would like to know, specifically, what packages did you tried and optionally, why did they fail? And if you develop ad-hoc logic (which i had too) which is required for it to come even close to working then who is going to maintain the data that drives this ad-hoc logic? If you think the users will then you are likely wrong because the same people who are capable of helping with this will find it less effort just to use the latest release and build some compatibility packages for the older stuff. If nobody is willing to provide sufficient data for the ad-hoc logic, then those packages should be black-listed. First of all that largely wouldnt be possible for your proposal. You also cant account for differences between releases (different releases can have the same version but entirely different features and dependencies). I actually encountered the dependency issue you stated. but I've solved that before, and I don't think it is impossible to convert my steps to code. Also minimum versions probably aren't enough. You would also need maximum versions to make your proposal work. I've consider that (thus the data file that keep the correct dependency), but thanks anyway. You may asked how this data file be generated. Well, at infant stage, it needs to be filled by the early adopters who crush into bugs. You are free to join the data file building. Don't use Denture if you are uncomfortable with that. You clearly don't know how many ways a package can fail. There are a lot of subtle advantages provided by the flow of updates during a release but Denture will be completely and utterly outside those comfortable walls. Package fails in old releases and current releases. But it's not end of world. Either file bug reports, fix it yourself, find alternative ones that do the same thing, or live with it. Given it's experimental nature, don't use Denture on the packages that is critical to your life, job or other thing you value much. Use Denture on the packages that, It's good to have, but can live without it. Perhaps that's why I haven't yet got bitten by extra bugs. If you really want a run down of some of the issues you will run into i can provide although i don't think the list is the place for them. Please mail me the issues that you encountered. Appreciated. I can also tell you the far simpler and more effective solution i came up with for your use case. It is also a frankly much more efficient use of the time. Instead create a program to generate side by side installable packages. Then you can use the latest release with all its features but your old programs that works better on an older Fedora has all the libs it needs to run. The whole concept is more efficient, easier to test, less likely to break systems, less dependent on the user, the type of user in your use case could deal with it more easily, etc and it also covers most of your use cases on your blog. I am interested in what you said, what do you mean side by side? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Selective updates are not really tested in practice and tend not to work. You're expected to get ALL stable updates, not just one. The old RHL advisories made this clear: | Before applying this update, make sure all previously released errata | relevant to your system have been applied. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. The word build there is another big fail. Users DO NOT WANT to build their packages from source. If they did, they'd all be using Gentoo! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Ding Yi Chen wrote: - John5342 john5...@googlemail.com wrote: I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. He was just explaining why packages tend not to have versioned dependencies in practice, and still work fine in supported Fedora releases. And you can't expect them to be fixed to support unsupported releases, those are unsupported for a reason. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. Specfiles are per definition distribution-specific. But this can be overcome by a datafile that stores correct version. Good luck maintaining that monster file! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 三，2009-07-08 於 11:37 +0200，Kevin Kofler 提到： Ding Yi Chen wrote: Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. The word build there is another big fail. Users DO NOT WANT to build their packages from source. If they did, they'd all be using Gentoo! Users with rpm building knowledge can build. Users came from FreeBSD and Gentoo are familar with build. Even those ex-Windows users, if there is good GUI that only require you to click on Next or Ok, they don't mind to build. *Sign*, well, How about following prompt: Denture will build the package for you, however, in order to do so, it will consume cpu time, disk space, network bandwidth, proceed? OK Cancel -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, 07 Jul 2009 00:18:51 +0200, Kevin wrote: Josh Boyer wrote: Fedora Legacy (the original one) failed. It failed because of excess bureaucracy (they didn't even trust Bugzilla's authentication, requiring GPG signing of all Bugzilla comments with impact on the procedures, and QA requirements were also unrealistic given the manpower). The manpower bottleneck affected it in two different areas. From the beginning on, the leadership failed to meet the requirements of the tiny base of people who actually prepared updates. The limited infrastructure made the manpower bottleneck worse, because only a very few people were permitted to rpmbuild/mach official update packages. Not enough people to cover all packages, which suffered from vulnerabilities. Not enough people to become a Fedora Legacy package owner or maintainer, who would also watch bugzilla for example. Not enough people with interest in those packages, not even in testing updates. It quickly became evident that a growing number of packages would remain vulnerable (or otherwise broken by a critical bug), because nobody wanted to take care of them. No inheritance of fedora.us' web of trust either. Even somebody, who copied and verified a patch from RHEL, couldn't move forward, because no second person acknowledged the pending updates in bugzilla. The old QA checklist was very short compared with Fedora's current guidelines -- still it had its enemies, especially those who would rather botch up a src.rpm and dump it into some /incoming place where others would need to pick it up and turn it into an official Fedora Legacy update. No quick leadership decisions to alter the policies and procedures. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 日，2009-07-05 於 12:32 +0200，Jeroen van Meeuwen 提到： On 07/05/2009 12:12 PM, Jos Vos wrote: On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). Agreed, I exaggerated a little there ;-) What I meant is they tend to need to run the latest and greatest *compared* to servers, and as you said, especially laptops and newer hardware. -- Jeroen Usually, people stick with older releases because they like to keep some packages/applications which are known to works on those releases. On the other hand, they may still want to upgrade other packages to obtain security fixes or crucial features. But the problem is, there is no unanimous way to determine what packages to keep and what packages to update, so generic Fedora legacy repository might not provide much help for those people, who actually need the legacy support. Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 02:30 AM, Josh Boyer wrote: Is there a reason any of that can't be done as a secondary arch-like effort? Nope. Not as far as I can see. I've already pointed out why it's painful to keep EOL releases around. You didn't really address those, and you seemed to have grouped them into minimal infrastructure effort. I didn't touch on package signing earlier, but that is another potential hurdle. Let me put is this way: None of the items I have listed are show-stoppers or insurmountable. However, unless someone comes forward with _concrete_ proposals on how to approach them and actual _people_ willing to work on it, they won't change. I don't think that is an undue burden to having this approved by a governing committee, whether it be FESCo or the Board. It's as simple as that. I think Jeroen understands that, and he seems to really want constructive criticism on the proposal. So I'll be happy to wait and see what comes of this. +1 to all of the above. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:37 AM, Kevin Fenzi wrote: On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Koflerkevin.kof...@chello.at wrote: Patrice Dumas's proposal failed because he wasn't provided with the required infrastructure (and he was unable to come up with it himself, which I can't blame him for). That was the time before last. The last one was in Feb by Scott Williams. I guess it just quietly faded out. Scott Williams was also required to build up his own infrastructure, which frankly is too much overhead in order to be able to start up the rest of it. Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be as is, if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. I think it is worse. It causes people to have an expectation that something will get security updates, and when it doesn't happen and they get compromised, they will not be very happy. The same goes for current releases, don't you think? Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
2009/7/7 Ding-Yi Chen dc...@redhat.com: 於 日，2009-07-05 於 12:32 +0200，Jeroen van Meeuwen 提到： On 07/05/2009 12:12 PM, Jos Vos wrote: On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). Agreed, I exaggerated a little there ;-) What I meant is they tend to need to run the latest and greatest *compared* to servers, and as you said, especially laptops and newer hardware. -- Jeroen Usually, people stick with older releases because they like to keep some packages/applications which are known to works on those releases. On the other hand, they may still want to upgrade other packages to obtain security fixes or crucial features. But the problem is, there is no unanimous way to determine what packages to keep and what packages to update, so generic Fedora legacy repository might not provide much help for those people, who actually need the legacy support. Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. Believe it or not i actually tried something similar for some of my internal servers and i like the idea but its impossible to get the dependencies right which makes the whole idea a no go. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:29 AM, Toshio Kuratomi wrote: On 07/06/2009 03:07 PM, Jesse Keating wrote: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. This one could be solved by having a separate component in bugzilla like Fedora Legacy, however that does move into a space that is visible to end users. Bug triage could probably move bugs from normal Fedora to Fedora Legacy if people were reporting against the correct version but incorrect product. For the Bugzilla gurus out there, to what extent is Bugzilla capable to Assign a bug to the owner of a package for a certain branch? Say I file a bug against foo in Fedora 8 now, and have ownership of the foo package in PackageDB... would the owner of the foo package in Fedora !8 branches be spammed with the Bugzilla report? Would it end up in his/her assigned list? I guess the example here is EPEL, which has a separate product Fedora EPEL in Bugzilla, no? I guess it would be doable to add a product Fedora End-Of-Sales or something (please avoid the Legacy or LTS names). -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:07 AM, Jesse Keating wrote: On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle When we talked at Berlin some of the details were a bit different, and I'll get to some of what I talked about there later in this email. First off, I think this is different from Fedora Legacy, or has potential to. Legacy had a few very key fail points. 1) it was opt in. Users had to know about it and actively enable it. 2) it was completely done outside of the Fedora infrastructure. 3) Fedora's popularity was very hit and miss, the type of people that would best use a Legacy like service were too burned to give any Red Hat related offering a shot. 4) RHEL4 (and its clones) were new enough for most of the people that would use this service, and thus they went that way. A longer Fedora sounds really great now, particularly because EL 5 and its clones are rather long in the tooth. How good it will sound once EL6 is out is a different matter. I think the popularity will wax and wane as the EL release cycles go. Like with anything else, though FY2010 is the right moment to start with, it has to grow organically and it will, or it won't, regardless of whether the timing is excellent -we would only need to take into account the release of EL6 from the perspective of expectations from our side. I think for this to succeed as an effort, which there is some folks whom state a need, I think there needs to be a few key things. * Automatic use. Users shouldn't have to opt-in to something different, they should have to do nothing and continue to get the updates. +1, no change on the consumer side may be required in order to have the ELC feature succeed. * A clarification of security updates. Will local denial of service (aka crash bug) be fixed? Local root escalation? Remote denial of service? Remote escalations? The amount of updates you will have to do will change dramatically based upon what level of security updates you want to target. http://www.redhat.com/security/updates/classification/ may help and may be familiar to the type of users you are targeting. I'll look into these details and try and elaborate on what I find -on the Feature page, so that this is (more) clear. Like I said before, I'm not in control and this is (going to be) a group effort so things may turn out a little different but we need to think about it anyway, so let's give it a shot beforehand. Thanks! * All or nothing. Either updates for whatever class you clarify from above will be provided for all packages, or none. There can't be any vagueness here. All, +1 * A way to prevent updates that do not match the above from being pushed. Ambiguity in what can be expected can cause confusion and fear. I realize that we have ambiguity during the normal release cycle and that is maintainer driven, but an extended support effort like this should clarify what will be offered. If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Without a guarantee for stable ABI/API or stable major/minor version numbers though some updates may have to be pushed as part of the dependency stack for a given security bug fix -or not. I guess we'll need to describe how this should be tackled exactly. * A measure of success. Some way that you can decide whether or not the Feature has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? * A timeline to go with the above to review for success/failure Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called Alpha freeze -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. * A responsible body behind the effort to make regular reports to FESCo/Board This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. Who is going to track and discover the security
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 01:06 AM, Kevin Fenzi wrote: On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwenkana...@kanarip.com wrote: Reading it on a question-mark per question-mark basis though, I think the feature page answers half of the half-posed questions. Anyway: - a bunch fas names? Approximate number? A bunch right now is approximately 25, including the people I've seen being enthusiastic in this thread or in private conversations. This doesn't mean I have 25 people lined up to do the actual work though, but for a single thread and some private communication (not fully exposed and not started yet), I think ~25 people is a strong start. When this comes up there is always A bunch of people who want this, but they never seem to want to sign up to do the work. Do you have such people ready to go to work? I can personally guarantee 1 FTE of work backing up this proposal for 6 months of extended life cycle support. - Are there any Corporations that specifically asked for this? Would they be willing to provide any resources to the effort? The demand is there..., the offerings... not so much. Maybe there's a trick to get sponsoring for something that does not and may not exist yet because approval is pending, that I don't know about. Care to share? Well, I would say gather your group, show that there is an active group of people ready to work on this and you will have a lot less skepticism. I personally look at the last time this came up. As far as I know the group had 1 meeting, nothing ever happened. Nothing ever got out, true. Some things did happen, such as building a large part of the infrastructure needed. It didn't live up to it's full potential though, agreed. I fear you are going to have to show some great setup and activity before people are going to take this seriously. :( What the conditions are for anyone out there to take this seriously or not, realistically, isn't my problem. I can't satisfy everybody in every aspect as you'll undoubtedly understand, but I can make sure valid concerns are addressed or taken into account prior to a decision being made on whether to allow this within and through the Fedora Project (as a Feature?). I should also note that I can not just share information on people interested or willing to do the work with you all, since I do not know or control their desired level of privacy. Either they step up and make themselves known to the world during one of these conversations, or they keep silent and you will never hear from then until after the discussion and the final decision -for whatever reason, I don't know. I'm sorry, but I choose to not be the one deciding whether people can opt-in later, at any given point, or whether they opt-in because I share their personal information. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 二，2009-07-07 於 14:44 +0100，John5342 提到： 2009/7/7 Ding-Yi Chen dc...@redhat.com: Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. All systems have bugs and may break. So you don't use any of them? :-) The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) Believe it or not i actually tried something similar for some of my internal servers and i like the idea but its impossible to get the dependencies right which makes the whole idea a no go. Believe it or not I actually tried something similar, but by hand though. I agree some maintainers does not accurately specify the dependency. but it is not beyond fix. One way to overcome this is maintaining a small datafile that contain the *true* dependency. Denture is not meant to be used to upgrade the whole system, but an automated tool to build a target package and corresponding mid-packages under specified constrain. So you only need to correct the dependencies of the target packages and mid-packages if you really need the target package. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... I like your signature. :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
2009/7/7 Ding-Yi Chen dc...@redhat.com: 於 二，2009-07-07 於 14:44 +0100，John5342 提到： 2009/7/7 Ding-Yi Chen dc...@redhat.com: Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. All systems have bugs and may break. So you don't use any of them? :-) Ofcourse all systems have bugs. However some are minor whilst others are so much work to make them usable that they are simply not worth it. Stuff that requires constant user intervention to cope with scenarios that cannot be automated is one such major issue. The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Wouldn't be spotted until it is used in your system. It wouldn't be used during standard usage because in a normal release both would be updated at the same time (or at least in the right order) so the scenario never happens. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. Of course Y can be updated but not necessarily to the required version. If the world was perfect all versions of packages would contain the exact versions required for things to work and your proposed system would either update fine or refuse to with a message if a dependency is blacklisted or unavailable as a recent enough version. However unfortunately for the same reasons i stated already virtually no package will state the dependant versions accurately enough to do what you want. But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. That is of course assuming X-1.3 has an explicit dependency on Y-1.3. It would be lovely if all packages has these versioned dependencies and a lot have automatically due to things like sonames but take the scenario where the soname is the same but the presence of the bug is not. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) Denture is not broken. Unfortunately though Denture only works in the ideal world. In reality though scenarios like i just mentioned happen all the time (along with many other similar issues) and the scenario i mentioned would break the users system and Denture has no way of knowing until it is too late. Believe it or not i actually tried something similar for some of my internal servers and i like the idea but its impossible to get the dependencies right which makes the whole idea a no go. Believe it or not I actually tried something similar, but by hand though. I agree some maintainers does not accurately specify the dependency. but it is not beyond fix. It is not some. It is more like most. How many packages do you see with the following for every single requires and build requires: BuildRequires: X-devel = X.X.X-X Requires: X = X.X.X-X And packagers shouldnt have to. apart from anything else it would mean that every single time somebody rebuilds a package all packages that depend on it would need rebuilding even if the update is binary compatible yet at the same time the only way to stop the scenario i mentioned from happening is to do exactly that. During a normal release bugs are easily spotted and fixed and scenarios like i mentioned will mostly never even happen anyway but mixing packages from different releases will potentially create an infinite number of combinations and almost certainly break. One way to overcome this is maintaining a small datafile that contain the *true* dependency. Denture is not meant to be used to upgrade the whole system, but an automated tool to build a target package and corresponding mid-packages under specified constrain. So you only need to correct the dependencies of the target packages and mid-packages if you really need the target package. -- There are 10 kinds of people in the
Re: Feature proposal: Extended Life Cycle Support
Ding-Yi Chen wrote: Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? As I've tried to explain to you last time you proposed that approach on your blog, that approach is completely broken by design and cannot work. Please go back to those blog posts and reread my comments. John5432's replies here also point out the issues. For example, you suggest blacklisting qt because of the renames, but that means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, the last release prior to the renames, is no longer supported.) You'll find that many of the packages you'll want to upgrade won't work because of some blacklisted dependency, and even where they appear to work, they might not actually work (see also John5432's point about unspecified minimum version dependencies). There's no way to just use the packages from a newer distribution on an older one, we have separate branches for a reason, there's no way around them. And your idea of cherry-picking individual packages for upgrading is just unsupportable. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Jeroen van Meeuwen wrote: Fedora End-Of-Sales or something (please avoid the Legacy or LTS names). End-Of-Sales doesn't make a lot of sense for something which isn't sold… Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Yeah, if you pick the line at say critical then every update would have a CVE, or would be bundled in bodhi with the package that had the CVE. So say webkit needs updating due to a CVE, you would bundle all the dependent packages in the same update, and the whole update itself would have the CVE listing, and would have just once announcement. Without a guarantee for stable ABI/API or stable major/minor version numbers though some updates may have to be pushed as part of the dependency stack for a given security bug fix -or not. I guess we'll need to describe how this should be tackled exactly. See above, should be how we do things now, group related updates into a single bodhi submission, and attach the bugs/CVEs to that single submission. * A measure of success. Some way that you can decide whether or not the Feature has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? Could go by time it takes to get a CVE discovered/fixed, how many are slipping through, karma on the updates, or just mirrormanager hits on the repos. * A timeline to go with the above to review for success/failure Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called Alpha freeze -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. I would think 6 months might be a little too short. Why not give it a year? * A responsible body behind the effort to make regular reports to FESCo/Board This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. You're driving the feature, but don't want to be responsible for the feature? odd? Who is going to track and discover the security issues? To be determined. Could be delegated to a (dedicated?) small(er) group of people within the SIG (to be set up) -maybe the not-so-technical??, or could be a responsible of each individual participating. Ok, so long as your aware that somebody or somebodies will need to monitor the entire package set for CVEs (something we're probably missing to some extent already). -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue July 7 2009, Jesse Keating wrote: See above, should be how we do things now, group related updates into a single bodhi submission, and attach the bugs/CVEs to that single submission. This may be disliked by upstream and others, because it creates bogus security update notification mails, that say that there are security updates for packages that are no security updates, e.g.: https://www.redhat.com/archives/fedora-package-announce/2008- September/msg00723.html Probably these mails are also parsed by third parties, e.g. LWN, because they also repeat that there were security issues in packages that did not have any security issues. Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, 2009-07-07 at 23:06 +0200, Till Maas wrote: This may be disliked by upstream and others, because it creates bogus security update notification mails, that say that there are security updates for packages that are no security updates, e.g.: https://www.redhat.com/archives/fedora-package-announce/2008- September/msg00723.html Probably these mails are also parsed by third parties, e.g. LWN, because they also repeat that there were security issues in packages that did not have any security issues. Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue July 7 2009, Jesse Keating wrote: Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When It was bundled with the packagate that had the security issue: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7976 the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. Yes, but Bodhi does not (or did not?) create such announcements. Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Jesse Keating wrote: Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. Because the fedora-package-announce mails are per updated package, not per grouped update. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, 2009-07-07 at 23:36 +0200, Kevin Kofler wrote: Jesse Keating wrote: Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. Because the fedora-package-announce mails are per updated package, not per grouped update. Kevin Kofler Perhaps it's time for that to change. Luke? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, Jul 07, 2009 at 03:33:27PM -0700, Jesse Keating wrote: On Tue, 2009-07-07 at 23:36 +0200, Kevin Kofler wrote: Jesse Keating wrote: Why was this update marked as security, but not bundled with the package that actually had the security issue that you were rebuilding for? When the entire list of packages is in one email then it makes sense. Such as https://rhn.redhat.com/errata/RHSA-2009-1095.html where all the packages are listed under one announcement instead of individually. Because the fedora-package-announce mails are per updated package, not per grouped update. Kevin Kofler Perhaps it's time for that to change. Luke? I suggest filing a ticket against bodhi instead of assuming this will magically be seen in the middle of a thread. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- John5342 john5...@googlemail.com wrote: 2009/7/7 Ding-Yi Chen dc...@redhat.com: 於 二，2009-07-07 於 14:44 +0100，John5342 提到： 2009/7/7 Ding-Yi Chen dc...@redhat.com: Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. All systems have bugs and may break. So you don't use any of them? :-) Of course all systems have bugs. However some are minor whilst others are so much work to make them usable that they are simply not worth it. Stuff that requires constant user intervention to cope with scenarios that cannot be automated is one such major issue. The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Wouldn't be spotted until it is used in your system. It wouldn't be used during standard usage because in a normal release both would be updated at the same time (or at least in the right order) so the scenario never happens. Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. Of course Y can be updated but not necessarily to the required version. If the world was perfect all versions of packages would contain the exact versions required for things to work and your proposed system would either update fine or refuse to with a message if a dependency is blacklisted or unavailable as a recent enough version. However unfortunately for the same reasons i stated already virtually no package will state the dependant versions accurately enough to do what you want. If what you said is completely true, I would not even bother to propose Denture. :-) But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. That is of course assuming X-1.3 has an explicit dependency on Y-1.3. It would be lovely if all packages has these versioned dependencies and a lot have automatically due to things like sonames but take the scenario where the soname is the same but the presence of the bug is not. If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Not to mention people who use rpm directly or build from srpm. So please file bug to X, don't blame Denture. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) Denture is not broken. Unfortunately though Denture only works in the ideal world. In reality though scenarios like i just mentioned happen all the time (along with many other similar issues) and the scenario i mentioned would break the users system and Denture has no way of knowing until it is too late. So do other package managers. Tell me, why are you so sure that the current version packages don't break the system secretly and user and the package managers has no way of knowing until it is too late? Believe it or not i actually tried something similar for some of my internal servers and i like the idea but its impossible to get the dependencies right which makes the whole idea a no go. Believe it or not I actually tried something similar, but by hand though. I agree some maintainers does not accurately specify the dependency. but it is not beyond fix. It is not some. It is more like most. How many packages do you see with the following for every single requires and build requires: BuildRequires: X-devel = X.X.X-X Requires: X = X.X.X-X After a quick peek of the packages I maintain or am interested in: 7 packages provide the version info of each dependency. 5 packages provide the version info for some
Re: Feature proposal: Extended Life Cycle Support
- Kevin Kofler kevin.kof...@chello.at wrote: Ding-Yi Chen wrote: Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? As I've tried to explain to you last time you proposed that approach on your blog, that approach is completely broken by design and cannot work. Please go back to those blog posts and reread my comments. John5432's replies here also point out the issues. I know what you were saying, but like I said to you: I have such system, I have motivation, I put some effort to try, and I succeed. I know some can be done and some would have serious consequences. You, on the other hand, don't have such motivation, never tried seriously, thus you think everything tend to be broken. :-) For example, you suggest blacklisting qt because of the renames, but that means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, the last release prior to the renames, is no longer supported.) If what you require is the latest Qt/KDE, then you may remove it from black-listed. But mind you, unless you know what you are doing and deal with it carefully, such action will break KDE3 apps such as kbabel. Of course, you can develop an ad-hoc logic for Denture to deal this problem, but currently I have no plan for it. You'll find that many of the packages you'll want to upgrade won't work because of some blacklisted dependency, I know. I wish IBus can run on RHEL5, but it cannot because it requires Python 2.5. I also know that Denture can tell me that such install/upgrade is not possible unless I remove Python form black-list and face all the consequences. and even where they appear to work, they might not actually work (see also John5432's point about unspecified minimum version dependencies). If that is the case, either file a bug to the package owners and ask them to correct the minimum version dependencies if the package version is covered by current supported released; or to Denture to override. There's no way to just use the packages from a newer distribution on an older one, we have separate branches for a reason, there's no way around them. And your idea of cherry-picking individual packages for upgrading is just unsupportable. Some packages can support the certain older releases, some packages don't. Blindly assuming all package versions can work with older releases will surely fail. Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
2009/7/8 Ding Yi Chen dc...@redhat.com: - John5342 john5...@googlemail.com wrote: 2009/7/7 Ding-Yi Chen dc...@redhat.com: 於 二，2009-07-07 於 14:44 +0100，John5342 提到： 2009/7/7 Ding-Yi Chen dc...@redhat.com: Any comments? In theory your proposal sounds great but i see just one major flaw that probably doesn't have a solution. Your idea of packages being built based on dependencies should work great apart from the fact that most packages don't tend to have hard dependencies on versions. Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later in the release cycle Y-1.3 is released followed later by X-1.3. Eve though X-1.3 actually requires Y-1.3 the maintainer probably never thinks to update the required version (assuming there even was one in the first place). Now your system can easily fail. It picks X-1.3 from F-11 (because thats the latest one) but Y-1.3 isn't allowed (because one of its dependencies is black listed) so it falls back to Y-1.2 which was the latest in F-10. Everything builds fine because they are source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your software is broken. All systems have bugs and may break. So you don't use any of them? :-) Of course all systems have bugs. However some are minor whilst others are so much work to make them usable that they are simply not worth it. Stuff that requires constant user intervention to cope with scenarios that cannot be automated is one such major issue. The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Wouldn't be spotted until it is used in your system. It wouldn't be used during standard usage because in a normal release both would be updated at the same time (or at least in the right order) so the scenario never happens. Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. Of course Y can be updated but not necessarily to the required version. If the world was perfect all versions of packages would contain the exact versions required for things to work and your proposed system would either update fine or refuse to with a message if a dependency is blacklisted or unavailable as a recent enough version. However unfortunately for the same reasons i stated already virtually no package will state the dependant versions accurately enough to do what you want. If what you said is completely true, I would not even bother to propose Denture. :-) What i said is plain and simple fact. The scenario i mentioned is one of several points of failure. I am not suggesting it is a problem with Denture itself but it is a problem with the real world. Thats just life. But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. That is of course assuming X-1.3 has an explicit dependency on Y-1.3. It would be lovely if all packages has these versioned dependencies and a lot have automatically due to things like sonames but take the scenario where the soname is the same but the presence of the bug is not. If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Not to mention people who use rpm directly or build from srpm. So please file bug to X, don't blame Denture. This isn't about whether Y-1.3 will be pulled in. If you do what the vast majority of users do then you will get the equivelant of yum update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 will still be updated siply because there is a later version. When you update using Denture however you could easily end up with X-1.3 and Y-1.2 for any number of reasons. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) Denture is not broken. Unfortunately though Denture only works in the ideal world. In reality though scenarios like i just mentioned happen all the time (along with many other similar issues) and the scenario i mentioned would break the users system and
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, Jul 06, 2009 at 10:27:43AM +0100, David Woodhouse wrote: On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? No, the sky does not fall. There are a few hurdles though. 1) Master mirror space. This used to be an issue, in that we had to move older releases to alt.fp.o in order to make space for the new release. I believe we still do that, so either the yum.repo.d config files for the EOL release would need to be changed, or we'd have to grow a lot more mirror space. 2) Update push times. It takes 3+ hours to mash f9-updates right now. Keeping that time duration in the official updates pushing for an EOL release would be really annoying. Particularly since we are already going to hit some major time hurdles as F10 and F11 age and definitely when we add F12. As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. It doesn't work that way in practice. If it is allowed, it is official. You have to coordinate downtimes, End-of-Life-After-Death times, etc. The minute it's disabled early for one reason or another (space, time constraints, etc) people will cry foul even if it was unofficial. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. I would encourage people to run this as a secondary architecture. CVS still remains open for commits. You could just have a secondary koji hub for the builds. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? There is minimal pain, yes. Mostly to infrastructure and rel-eng. What I don't immediately see is the benefit to Fedora overall. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 06 Jul 2009 02:03:01 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Jeroen van Meeuwen wrote: Whether 6 months of additional availability of security updates is going to help, and to what extend, we'll have to see. Compared to the current situation, that'll give an environment 7 months to upgrade beyond the moment that we now call End-Of-Life for a given release and 3 releases to choose from -certainly a lot more time then 1 month and 2 releases to choose from. They already have 7 months of time to move to the next version. It's just if they absolutely want to skip a version that they only have 1 month. True, but consider that moving to Fedora N+1 requires one to reconsider within 6 months. As such I'd say choosing the Fedora N+1 option when Fedora N+2 does not meet ones needs or expectations and one decides to put off on upgrading to Fedora N+2, leaves them with a one month upgrade opportunity after Fedora N+3's GA after all, and so is not exactly without penalty. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
2009/7/6 Jeroen van Meeuwen kana...@kanarip.com: On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? That plus the fact that you have Red Hat, the major backers of Fedora, producing a distribution that is geared towards long term support for their clients. Hence any initiative to increase the length of time Fedora is supported will not (I believe) receive anything more than lip service from RH. I completely understand that and it makes financial sense. The more you try and give Fedora some kind of LTS, the more you stray into territory already covered by RHEL (paid support) or CentOS (unpaid support). I was simply trying to identify what the requirements are for LTS on Fedora. I think simply saying Fedora needs LTS is doomed as the past has proved. Those that forget the past are doomed to repeat it. - George Santayana The sooner Fedora gets out of its identity crisis the better. I believe the following: Fedora is the distribution for those who love computers. CentOS, Ubuntu and others are for those who dont. Regards -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 06 Jul 2009 10:27:43 +0100, David Woodhouse dw...@infradead.org wrote: On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. Hold on... Realistically, the current 13 month life cycle is about 7-8 months too long for me personally as I upgrade to rawhide anywhere between Beta and GA everywhere I can ;-) This extended life cycle feature is not to support my own needs and/or expectations. The longer (3 year approx.) release cycle doesn't necessarily disqualify a distribution for desktop environments, but for some environments that have a desire to run newer software. The shorter life cycle (~13 months) however is a major downside to many businesses -in my experience. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. As the page says, at: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes my initial thoughts are 6 months extra (~19 months total). This will give us enough time to establish whether this is successful (although not meeting it's full potential success after this short a period of time), and whether this is sustainable. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? Overall, roughly estimated, it'll take 1 FTE to do all the work involved. Whether that is one person doing all the work (including patching, building, maintaining infra, pushing, signing, etc, etc..), or 80 people doing all kinds of various stuff, doesn't matter; It'd still come down to approximately 1 FTE. As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. As suggested on the wiki page, we rename EOL to End-Of-Support (EOS), only to make a given release EOL after the period of time we decide to provide security updates for. Of course, not renaming EOL to EOS does not block anything from moving forward. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? Thank you, Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009, Christopher Brown wrote: The sooner Fedora gets out of its identity crisis the better. I believe the following: Fedora is the distribution for those who love computers. CentOS, Ubuntu and others are for those who dont. well, crap. I guess I'm in the wrong place ;) -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 07:11:30 -0400, Josh Boyer jwbo...@gmail.com wrote: No, the sky does not fall. There are a few hurdles though. 1) Master mirror space. This used to be an issue, in that we had to move older releases to alt.fp.o in order to make space for the new release. I believe we still do that, so either the yum.repo.d config files for the EOL release would need to be changed, or we'd have to grow a lot more mirror space. 2) Update push times. It takes 3+ hours to mash f9-updates right now. Keeping that time duration in the official updates pushing for an EOL release would be really annoying. Particularly since we are already going to hit some major time hurdles as F10 and F11 age and definitely when we add F12. These are very valid constraints/concerns which I've added to the Feature wiki page. This is stuff I like to hear ;-) It doesn't work that way in practice. If it is allowed, it is official. You have to coordinate downtimes, End-of-Life-After-Death times, etc. The minute it's disabled early for one reason or another (space, time constraints, etc) people will cry foul even if it was unofficial. This (downtimes, etc) is why initially, I wanted the period of time between EOS and EOL to match a release cycle. I guess these dependencies make it a little more required to stick with periods of time equal to the release-cycle of a Fedora release. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. I would encourage people to run this as a secondary architecture. CVS still remains open for commits. You could just have a secondary koji hub for the builds. It that's the solution to problems (to be) set forth, then so be it. I would love to have it as part of the primary infrastructure but then again it's no blocker. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? There is minimal pain, yes. Mostly to infrastructure and rel-eng. What I don't immediately see is the benefit to Fedora overall. Is it you question the benefit given in the paragraph on the Feature page, or ...? Thanks, Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 16:25:08 +0100, Christopher Brown snecklif...@gmail.com wrote: 2009/7/6 Jeroen van Meeuwen kana...@kanarip.com: On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? That plus the fact that you have Red Hat, the major backers of Fedora, producing a distribution that is geared towards long term support for their clients. Hence any initiative to increase the length of time Fedora is supported will not (I believe) receive anything more than lip service from RH. I completely understand that and it makes financial sense. lip service doesn't translate very well but I think I got the clue; If you're saying that Red Hat would choose to not support this initiative for whatever their reasons, may be, then so be it. I can't control what they do and I wouldn't want to. I can control however what I do with or without Red Hat's blessing. I was simply trying to identify what the requirements are for LTS on Fedora. I think simply saying Fedora needs LTS is doomed as the past has proved. Those that forget the past are doomed to repeat it. - George Santayana I'm too eager to respond with similar phrases as put onto the Feature wiki page; if the difference between the long term support model for RHEL and an extended life cycle model for Fedora isn't clear enough, then how can I explain the added value of a commercial company backing it's product, stable API/ABI offerings, hardware and software certifications, a phone number, the differences between 7 years or 19 months, desktop environments vs. enterprise solutions, prolonged availability of security updates (only!) vs. prolonged application support (including security updates), and the difference between 19 months and 3 years? The sooner Fedora gets out of its identity crisis the better. I wholeheartedly agree, but it's a completely different discussion. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/05/2009 03:28 AM, Jeroen van Meeuwen wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Instead of saying yet to be determined, put in the actual number of say 20 months there in the summary upfront. The FAQ should also answer How is this going to succeed, where Fedora Legacy failed?. You should put in a place for people to sign up for this effort. If more people volunteer, it would make answer the question on who is actually going to do this. Is opt-in ELC support for every release or is it going to be an experimental effort just for Fedora 12 to evaluate feasibility? How would you prefer to brand it? Would maintenance of packages be available for a separate ELC support team if the primary maintainers are not interested? Do you want to focus on a core set of packages instead of everything? If people had a better handle on what exactly they are volunteering for, more of them might. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, Jul 06, 2009 at 11:16:45AM -0500, Rex Dieter wrote: Jeroen van Meeuwen wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle As one who could directly benefit (@ work) and participate in such a venture, I would support it and participate. In the previous try I remember that Kevin Kofler, Orion, Ralf Corsepius and Manuel were interested. I was too, but I am not in fedora anymore. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, Jul 06, 2009 at 09:50:53PM +0530, Rahul Sundaram wrote: The FAQ should also answer How is this going to succeed, where Fedora Legacy failed?. You should this was debated a lot in the previous attempts, and I still think that any attempt to do this with fedora infra (not necessarily speaking about resources, but more about policies) is very different from Fedora Legacy. The policies of fedora legacy were very different than in fedora extras in these days, and I think this is one of the reasons why it failed. At least it is why I didn't stepped in, although I was very interested. This is not a valid point of comparison. EPEL is certainly a much more relevant point of comparison. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sat, 04 Jul 2009 23:58:52 +0200 Jeroen van Meeuwen kana...@kanarip.com wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Kind regards, Some general comments: - Have you talked with the last folks that attempted this? https://www.redhat.com/archives/fedora-advisory-board/2009-February/msg00030.html http://docs.google.com/Doc?id=dc7dcczk_2fxtsctdqhl=en - The issue I have with this plan (and the others very like it) is that if you say we will just do updates for the things we have people willing to do updates it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. - An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here? - Have you considered leveraging the 'critical path' proposal? Try and up front get enough folks to cover all the critical path packages and expand from there? - How many people are on board with this? Do you have guidelines for what will be updated or not? what packages? Version updates ok? Or only security fixes? - Are there any Corporations that specifically asked for this? Would they be willing to provide any resources to the effort? Just a few thoughts... Jeroen van Meeuwen -kanarip kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Kevin Fenzi (ke...@scrye.com) said: - The issue I have with this plan (and the others very like it) is that if you say we will just do updates for the things we have people willing to do updates it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. - An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here? These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. Other notes: - while F9 updates may be 3+ hours, F11 updates is currently *14-15* hours, and there aren't as many updates now as there will be; that number will only go up. (Yay deltarpms!) - You don't provide API/ABI guarantees. Which means you're signing up for more work than you might want if you're pushing updates to Firefox/xulrunner. (And if you're not providing updates for that for the desktop, it's not worth starting.) - You state that the only reason that makes upgrading the distribution a requirement is the continuous availability of security updates. This implies that you're fine with the feature set of an older distribution after a while; but you don't want something like RHEL or CentOS. Is it just the 'RHEL is sort of old in the tooth right now' sort of philosophy? Because by your metrics, a RHEL released now (or in 3 months, or whatever) would be fine. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham nott...@redhat.com wrote: Kevin Fenzi (ke...@scrye.com) said: - The issue I have with this plan (and the others very like it) is that if you say we will just do updates for the things we have people willing to do updates it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. - An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here? These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. This has been addressed in another response to the quoted message from Kevin. Other notes: - while F9 updates may be 3+ hours, F11 updates is currently *14-15* hours, and there aren't as many updates now as there will be; that number will only go up. (Yay deltarpms!) The support of deltarpms within the extended life cycle is something that can be (re-)considered. - You don't provide API/ABI guarantees. Which means you're signing up for more work than you might want if you're pushing updates to Firefox/xulrunner. (And if you're not providing updates for that for the desktop, it's not worth starting.) Thanks for the heads-up. - You state that the only reason that makes upgrading the distribution a requirement is the continuous availability of security updates. This implies that you're fine with the feature set of an older distribution after a while; but you don't want something like RHEL or CentOS. Is it just the 'RHEL is sort of old in the tooth right now' sort of philosophy? Because by your metrics, a RHEL released now (or in 3 months, or whatever) would be fine. The or whatever is sorta funny... (1) The opt-in upgrade every 3 years or every 6 months is a *major* difference. (2) The required upgrade every 7 years or every year is a *major* difference. At point 1 where RHEL is released, it might be fine. At point 2 where Fedora N+1 is released RHEL gets old. You have another 4 (!) Fedora releases (do I hear anyone say ~20 features each?) coming your way to make you appreciate the more rapid release cycle; if only you didn't hate the rapid required upgrade cycle as much... Now, if one could opt-in to upgrade every 6 months for a longer period of time, say 19 months instead of 13 months (leaving 7 or 1 month(s) respectively to upgrade to N+1 or N+2, as said before), then I foresee greater adoption and thus potentially greater participation. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Jeroen van Meeuwen (kana...@kanarip.com) said: These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. This has been addressed in another response to the quoted message from Kevin. OK. When you state in the feature page: Note that the following items may only apply to those that opt-in on ELC support that implies that it would not apply to every package. Or are you referring to 'users who opt-in to use ELC'? Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? Probably, yes. But this is why I think the specific amount of extension is a good idea to state - it makes the proposal more actionable. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/05/2009 11:46 AM, Jon Stanley wrote: On Sun, Jul 5, 2009 at 6:12 AM, Jos Vosj...@xos.nl wrote: I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops I don't agree with that position either - note my work laptop, which unfortunately runs Windows. However, just to make a point, it runs Windows XP Pro, and Office 2003 - hardly the latest and greatest that Microsoft has to offer. A RHEL 5 desktop would provide me similarly aged (or newer) software. RHEL/CentOS also gets hardware enablement throughout it's lifecycle, so the newer laptops need newer software only holds true through the beginning of the Production 2 support phase at minimum, by which time the next release of RHEL should be available (for RHEL 5, this date is 3/31/2011) I think the notion that desktops need newer software is all a side effect of where Linux was when RHEL came out (and may continue to be a side effect of where it is now). Desktop linux is largely new, groundbreaking stuff. It can't be too old before it starts to have limbs missing. Older Linux desktop software isn't bad because its old, its bad because its unfinished. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/05/2009 08:03 PM, Kevin Kofler wrote: They already have 7 months of time to move to the next version. It's just if they absolutely want to skip a version that they only have 1 month. In the field I've often found that a Fedora at GA+0 isn't really ready to deploy. A bunch of fixes come in quickly, and things are mostly rock-solid by 2 months in, maybe 3. So, one can't really plan to skip versions and remain stable - 1 month is too short. One way to look at this project, then, would be to extend the EOL of the previous version by that period (however it could be rigorously defined). That would enable effective version skipping, thus doubling the effective life of a release. The tools required to make a 2-version skip dependable would be another useful avenue. WRT Legacy, that was done before the Extras merge, right? Did Legacy handle Extras? I don't recall, but if not that could make this incarnation that many times more difficult. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle When we talked at Berlin some of the details were a bit different, and I'll get to some of what I talked about there later in this email. First off, I think this is different from Fedora Legacy, or has potential to. Legacy had a few very key fail points. 1) it was opt in. Users had to know about it and actively enable it. 2) it was completely done outside of the Fedora infrastructure. 3) Fedora's popularity was very hit and miss, the type of people that would best use a Legacy like service were too burned to give any Red Hat related offering a shot. 4) RHEL4 (and its clones) were new enough for most of the people that would use this service, and thus they went that way. A longer Fedora sounds really great now, particularly because EL 5 and its clones are rather long in the tooth. How good it will sound once EL6 is out is a different matter. I think the popularity will wax and wane as the EL release cycles go. I think for this to succeed as an effort, which there is some folks whom state a need, I think there needs to be a few key things. * Automatic use. Users shouldn't have to opt-in to something different, they should have to do nothing and continue to get the updates. * A clarification of security updates. Will local denial of service (aka crash bug) be fixed? Local root escalation? Remote denial of service? Remote escalations? The amount of updates you will have to do will change dramatically based upon what level of security updates you want to target. http://www.redhat.com/security/updates/classification/ may help and may be familiar to the type of users you are targeting. * All or nothing. Either updates for whatever class you clarify from above will be provided for all packages, or none. There can't be any vagueness here. * A way to prevent updates that do not match the above from being pushed. Ambiguity in what can be expected can cause confusion and fear. I realize that we have ambiguity during the normal release cycle and that is maintainer driven, but an extended support effort like this should clarify what will be offered. * A measure of success. Some way that you can decide whether or not the Feature has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way * A timeline to go with the above to review for success/failure * A responsible body behind the effort to make regular reports to FESCo/Board Some other interesting problems: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. Who is going to track and discover the security issues? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Josh Boyer wrote: Fedora Legacy (the original one) failed. It failed because of excess bureaucracy (they didn't even trust Bugzilla's authentication, requiring GPG signing of all Bugzilla comments with impact on the procedures, and QA requirements were also unrealistic given the manpower). The last time something like this was proposed, it generated a few meetings and some discussion here and on f-a-b. I have yet to see anything actually come of that. Patrice Dumas's proposal failed because he wasn't provided with the required infrastructure (and he was unable to come up with it himself, which I can't blame him for). Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be as is, if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/06/2009 03:07 PM, Jesse Keating wrote: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. This one could be solved by having a separate component in bugzilla like Fedora Legacy, however that does move into a space that is visible to end users. Bug triage could probably move bugs from normal Fedora to Fedora Legacy if people were reporting against the correct version but incorrect product. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Josh Boyer wrote: Fedora Legacy (the original one) failed. It failed because of excess bureaucracy (they didn't even trust Bugzilla's authentication, requiring GPG signing of all Bugzilla comments with impact on the procedures, and QA requirements were also unrealistic given the manpower). The last time something like this was proposed, it generated a few meetings and some discussion here and on f-a-b. I have yet to see anything actually come of that. Patrice Dumas's proposal failed because he wasn't provided with the required infrastructure (and he was unable to come up with it himself, which I can't blame him for). That was the time before last. The last one was in Feb by Scott Williams. I guess it just quietly faded out. Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be as is, if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. I think it is worse. It causes people to have an expectation that something will get security updates, and when it doesn't happen and they get compromised, they will not be very happy. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwen kana...@kanarip.com wrote: On Mon, 6 Jul 2009 10:57:34 -0600, Kevin Fenzi ke...@scrye.com wrote: ...snip... - The issue I have with this plan (and the others very like it) is that if you say we will just do updates for the things we have people willing to do updates it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. This issue depends on an if, and is thus invalid. Maybe what you wanted to say/ask is along the lines of: Are you planning on only providing updates for the packages you have maintainers for?. In that case; The question doesn't make any sense -given that the Feature page does not say only a selection of packages. To put it in understandable English: We are not going to selectively supply updates for a limited number of packages, it's either all or nothing. Great. I did read the page and didn't get that impression... The Note that the following items may only apply to those that opt-in on ELC support confused me perhaps? 6 months is our initial life cycle extension, as the page says. I feel like everyone missed that. ok. I guess I missed it too. Who am I to set the extended life cycle when various people participate...? I'm not in control! Would the period of time to extend the life cycle with not be the first agenda item at a meeting of peers interested and/or participating? I made one suggestion to start out with, 6 months, put it on the Feature page and no-one reads it. Frankly those 6 months are not set in stone -it's just a proposal for the bunch of people interested and a guideline for others -including those deciding on whether this feature is in or out. Regrettably, some of these people feel like they *are* in control, rather then providing the governance they should. Different subject though. ok. How about having a meeting and deciding that before trying to get the proposal off the ground? - How many people are on board with this? Do you have guidelines for what will be updated or not? what packages? Version updates ok? Or only security fixes? This is a lot of questions for one bullet point. I lost you half-way through. What's the actual question here? Sorry, Should have split it out. Reading it on a question-mark per question-mark basis though, I think the feature page answers half of the half-posed questions. Anyway: - a bunch fas names? Approximate number? When this comes up there is always A bunch of people who want this, but they never seem to want to sign up to do the work. Do you have such people ready to go to work? - everything that needs to be updated to ensure prolonged security fixes' availability for any given Fedora release - only security fixes - no guarantee for stable API/ABI - no guarantee for binary compatibility throughout the life cycle great. - Are there any Corporations that specifically asked for this? Would they be willing to provide any resources to the effort? The demand is there..., the offerings... not so much. Maybe there's a trick to get sponsoring for something that does not and may not exist yet because approval is pending, that I don't know about. Care to share? Well, I would say gather your group, show that there is an active group of people ready to work on this and you will have a lot less skepticism. I personally look at the last time this came up. As far as I know the group had 1 meeting, nothing ever happened. I fear you are going to have to show some great setup and activity before people are going to take this seriously. :( kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Tue, Jul 07, 2009 at 12:18:51AM +0200, Kevin Kofler wrote: Josh Boyer wrote: Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be as is, if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. Is there a reason any of that can't be done as a secondary arch-like effort? I've already pointed out why it's painful to keep EOL releases around. You didn't really address those, and you seemed to have grouped them into minimal infrastructure effort. I didn't touch on package signing earlier, but that is another potential hurdle. Let me put is this way: None of the items I have listed are show-stoppers or insurmountable. However, unless someone comes forward with _concrete_ proposals on how to approach them and actual _people_ willing to work on it, they won't change. I don't think that is an undue burden to having this approved by a governing committee, whether it be FESCo or the Board. It's as simple as that. I think Jeroen understands that, and he seems to really want constructive criticism on the proposal. So I'll be happy to wait and see what comes of this. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/06/2009 09:19 PM, Bill Nottingham wrote: Jeroen van Meeuwen (kana...@kanarip.com) said: These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. This has been addressed in another response to the quoted message from Kevin. OK. When you state in the feature page: Note that the following items may only apply to those that opt-in on ELC support that implies that it would not apply to every package. Or are you referring to 'users who opt-in to use ELC'? Between packages and maintainers, only maintainers are in a position to opt-in. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? Probably, yes. But this is why I think the specific amount of extension is a good idea to state - it makes the proposal more actionable. And it is proposed, it's just not everywhere in the text: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). The problem I have with this whole project is that nobody explained me well, why you folks interested in this don't join CentOS project? NIH? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 05/07/09 07:20, Matej Cepl wrote: Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: snip The problem I have with this whole project is that nobody explained me well, why you folks interested in this don't join CentOS project? NIH? Matěj Possibly because CentOS is not Fedora. Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 06:20:38 + (UTC), Matej Cepl mc...@redhat.com wrote: Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). The problem I have with this whole project is that nobody explained me well, why you folks interested in this don't join CentOS project? NIH? The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/05/2009 12:12 PM, Jos Vos wrote: On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). Agreed, I exaggerated a little there ;-) What I meant is they tend to need to run the latest and greatest *compared* to servers, and as you said, especially laptops and newer hardware. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, Jul 5, 2009 at 5:39 AM, David Woodhouse dw...@infradead.org wrote: On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Out of curiosity, don't we have an Extended Life Cycle Fedora version called Red Hat Enterprise Linux and/or CentOS and/or dozens of other similar distros? Why duplicate efforts? Just so it goes under the name Fedora? -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, Jul 5, 2009 at 6:12 AM, Jos Vosj...@xos.nl wrote: I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops I don't agree with that position either - note my work laptop, which unfortunately runs Windows. However, just to make a point, it runs Windows XP Pro, and Office 2003 - hardly the latest and greatest that Microsoft has to offer. A RHEL 5 desktop would provide me similarly aged (or newer) software. RHEL/CentOS also gets hardware enablement throughout it's lifecycle, so the newer laptops need newer software only holds true through the beginning of the Production 2 support phase at minimum, by which time the next release of RHEL should be available (for RHEL 5, this date is 3/31/2011) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 05 Jul 2009 11:39:44 +0100, David Woodhouse dw...@infradead.org wrote: On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, Jul 5, 2009 at 11:03 AM, Jeroen van Meeuwenkana...@kanarip.com wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? No, it doesn't make a great deal of sense. You say a market for this is the corporate desktop, but a government department I work with runs their scientific desktops on RHEL 4. They have a lot of in-house apps that are known to work on that platform. There is absolutely no sense in expending resources on switching to a newer version until that version's EOL is in sight. -- Mat Booth www.matbooth.co.uk -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 22:13 +0100, Christopher Brown wrote: 2009/7/4 Jeroen van Meeuwen kana...@kanarip.com: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle Perhaps a way to do this would be to identify what the latest and greatest is that users want and make _that_ run on Centos. Here's my list: OO.org Firefox Thunderbird Evolution with MAPI connector GNOME-RDP Amarok There is a fast track channel for RHEL5 that is supposed to provide early updates of at least some apps. I can only see MAPI being a problem requiring some Samba 4 stuff. Much worse than that. The MAPI evo is 2.26, but RHEL5's is 2.16. You'd have to upgrade the entire GNOME infrastructure to support the MAPI stuff. From the discussions I've read, back-porting MAPI support is not practical. Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. Regards -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
Hi. On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. Is it that time of the year again? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 00:22 +0200, Ralf Ertzinger wrote: On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. Is it that time of the year again? Geez, I was going to say thing. Didn't we have this discussion about 8 months ago? Later, /B -- Brian Pepple bpep...@fedoraproject.org identi.ca: http://identi.ca/bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sat, Jul 4, 2009 at 6:39 PM, Brian Pepple bpep...@fedoraproject.orgwrote: On Sun, 2009-07-05 at 00:22 +0200, Ralf Ertzinger wrote: On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. Is it that time of the year again? Geez, I was going to say thing. Didn't we have this discussion about 8 months ago? Later, /B How about Reduced Life Cycle, I'd like to get to F30 quicker! -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 00:22:41 +0200, Ralf Ertzinger fed...@camperquake.de wrote: Hi. On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. Is it that time of the year again? BINGO! The first response spawns a dead branch to this thread, congratulations! -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
https://fedoraproject.org/wiki/Features/Extended_Life_Cycle reads: Say a desktop environment runs Fedora 9 today, then within a month after Fedora 11 is released, the user can choose to either upgrade to Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable amount of time for corporate desktop environments, where projects need to be defined, testing needs to be performed, resources have to be alocated, etc, before any of the actual work can be done. To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. People hate work, and it would be a lot of work to maintain 5 or even six parallel versions of Fedora. Maybe something like a Fedora LTS version is more likely to be a success. But hey, I like the idea behind it, let's see how it develops. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi julian.fedorali...@googlemail.com wrote: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle reads: Say a desktop environment runs Fedora 9 today, then within a month after Fedora 11 is released, the user can choose to either upgrade to Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable amount of time for corporate desktop environments, where projects need to be defined, testing needs to be performed, resources have to be alocated, etc, before any of the actual work can be done. To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). People hate work, and it would be a lot of work to maintain 5 or even six parallel versions of Fedora. Maybe something like a Fedora LTS version is more likely to be a success. While of course we'd never call it LTS, and while LTS has a very much different value proposition then what is in the current proposal (LTS is just too hard to start with at this moment), the 13 months we have now is most definitely not suitable for corporate environments. Whether 6 months of additional availability of security updates is going to help, and to what extend, we'll have to see. Compared to the current situation, that'll give an environment 7 months to upgrade beyond the moment that we now call End-Of-Life for a given release and 3 releases to choose from -certainly a lot more time then 1 month and 2 releases to choose from. I doubt whether the first six months will meet it's full potential in terms of success since the feature will need to be known to consumers, and just having it available does not make environments use Fedora all of a sudden. That too needs time to settle. Also, I should mention that in my experience, businesses that do choose Fedora despite the requirement of one upgrade per year, tend to upgrade within month 7-9 of a given release as long as you give them the full details on how to make it easier on themselves; (Revisor, optional) - Cobbler - Puppet. But hey, I like the idea behind it, let's see how it develops. Thanks ;-) I'm sure this will be continued ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
