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,
Jeroen van Meeuwen -kanarip
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
On Sat, Jul 4, 2009 at 6:39 PM, Brian Pepple bpepple@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!
On Sun, 5 Jul 2009 00:22:41 +0200, Ralf Ertzinger fedora@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
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.
On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi julian.fedoralists@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
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
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
On Sun, 5 Jul 2009 06:20:38 +0000 (UTC), Matej Cepl mcepl@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
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).
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
於 日,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?
2009/7/7 Ding-Yi Chen dchen@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.
於 二,2009-07-07 於 14:44 +0100,John5342 提到:
2009/7/7 Ding-Yi Chen dchen@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. :-)
2009/7/7 Ding-Yi Chen dchen@redhat.com:
於 二,2009-07-07 於 14:44 +0100,John5342 提到:
2009/7/7 Ding-Yi Chen dchen@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 world: Those who understand binary and those who don't...
I like your signature. :-)
Thanks :)
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
On Sun, Jul 5, 2009 at 6:12 AM, Jos Vosjos@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)
On 07/05/2009 11:46 AM, Jon Stanley wrote:
On Sun, Jul 5, 2009 at 6:12 AM, Jos Vosjos@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
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.
On Sun, Jul 5, 2009 at 5:39 AM, David Woodhouse dwmw2@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 Woodhouse Open Source Technology Centre David.Woodhouse@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"?
On Sun, 05 Jul 2009 11:39:44 +0100, David Woodhouse dwmw2@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
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?
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
On Mon, 6 Jul 2009 07:11:30 -0400, Josh Boyer jwboyer@gmail.com wrote:
No, the sky does not fall. There are a few hurdles though.
- 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.
- 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
On Mon, Jul 06, 2009 at 05:36:25PM +0200, Jeroen van Meeuwen wrote:
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 ...?
Yes, I question the benefit listed in the Feature page. I have personally seen evidence to the contrary that the current release cycles are too short to enable corporate usage. However, I have no doubt that you could also come up with data supporting your claim.
I am simply not convinced (yet) that the stated benefit is enough to warrant the cost. This does not mean you are wrong, and I do not want to get into a bikeshed argument about it.
josh
On Mon, 6 Jul 2009 11:59:48 -0400, Josh Boyer jwboyer@gmail.com wrote:
On Mon, Jul 06, 2009 at 05:36:25PM +0200, Jeroen van Meeuwen wrote:
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 ...?
Yes, I question the benefit listed in the Feature page. I have
personally
seen evidence to the contrary that the current release cycles are too
short
to enable corporate usage. However, I have no doubt that you could also come up with data supporting your claim.
I am simply not convinced (yet) that the stated benefit is enough to warrant the cost. This does not mean you are wrong, and I do not want to get
into
a bikeshed argument about it.
Neither do I, but I'll take your doubts and see what I can do about them (through the Feature page), if anything.
If only we could put out finger on the actual cost, or even just put our finger on the actual benefit, things would be a little clearer, but regrettably, the figures are unavailable until after we try :/
I guess that *who* does (is going to do, would be doing) the actual work is of significant importance as well.
-- Jeroen
On Mon, 06 Jul 2009 10:27:43 +0100, David Woodhouse dwmw2@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
On Sun, Jul 5, 2009 at 11:03 AM, Jeroen van Meeuwenkanarip@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.
On Sun, Jul 05, 2009 at 06:40:37PM +0100, Mat Booth wrote:
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.
But these requirements are certainly not the same for every customer.
One desktop customer running RHEL5 already complains about the version of OpenOffice. For that reason (and some others) we are thinking of migrating their desktops (not their server) to F11.
And using OpenOffice (and requiring maximal MS-Office compatibility for communicating with the evil world) can't be seen as an exotic requirement for a desktop, IMHO...
On Sun, 5 Jul 2009 18:40:37 +0100, Mat Booth fedora@matbooth.co.uk wrote:
On Sun, Jul 5, 2009 at 11:03 AM, Jeroen van Meeuwenkanarip@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.
You just made (part of) my point, I hope you realize:
There is absolutely no sense in expending resources on switching to a newer version until that version's EOL is in sight.
Thanks!
Also, note that one example of a corporate environment that runs Enterprise Linux grade distributions on their desktop systems does not make the rest less true. And before anyone else is going to say it; I bet there's dozens if not hundreds if not thousands if not millions of similar environments happy to run with the Enterprise Linux distributions out there.
Kind regards,
Jeroen van Meeuwen -kanarip
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.
Kevin Kofler
On Mon, 06 Jul 2009 02:03:01 +0200, Kevin Kofler kevin.kofler@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
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
2009/7/4 Jeroen van Meeuwen kanarip@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
I can only see MAPI being a problem requiring some Samba 4 stuff.
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
On Sun, 2009-07-05 at 22:13 +0100, Christopher Brown wrote:
2009/7/4 Jeroen van Meeuwen kanarip@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
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklifter@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
2009/7/6 Jeroen van Meeuwen kanarip@kanarip.com:
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklifter@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
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
On Mon, 6 Jul 2009 16:25:08 +0100, Christopher Brown snecklifter@gmail.com wrote:
2009/7/6 Jeroen van Meeuwen kanarip@kanarip.com:
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklifter@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
On Mon, Jul 06, 2009 at 04:25:08PM +0100, Christopher Brown wrote:
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).
The term "unpaid support" sounds very misleading. You can also buy paid support from various companies for CentOS and other rebuilds. For the rest, there is no formal support (with support I mean here somthing you can count on).
On Mon, Jul 06, 2009 at 05:13:45PM +0200, Jeroen van Meeuwen wrote:
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklifter@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?
Hyperbole aside, ignoring history doesn't seem prudent.
Fedora Legacy (the original one) failed.
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.
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.
josh
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
On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Kofler kevin.kofler@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
On 07/07/2009 12:37 AM, Kevin Fenzi wrote:
On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Koflerkevin.kofler@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
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
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
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.
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.
-- Rex
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
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
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
On 07/06/2009 09:59 PM, Patrice Dumas wrote:
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.
You may be right but answering this question upfront in the feature page will help move the discussions to other important issues. I would be more willing to support this effort and get involved if the questions were answered convincingly.
Rahul
On Sat, 04 Jul 2009 23:58:52 +0200 Jeroen van Meeuwen kanarip@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... http://docs.google.com/Doc?id=dc7dcczk_2fxtsctdq&hl=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
Kevin Fenzi (kevin@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
On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham notting@redhat.com wrote:
Kevin Fenzi (kevin@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
Jeroen van Meeuwen (kanarip@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
On 07/06/2009 09:19 PM, Bill Nottingham wrote:
Jeroen van Meeuwen (kanarip@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
On Mon, 6 Jul 2009 10:57:34 -0600, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 04 Jul 2009 23:58:52 +0200 Jeroen van Meeuwen kanarip@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...
http://docs.google.com/Doc?id=dc7dcczk_2fxtsctdq&hl=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.
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.
- An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here?
6 months is our initial life cycle extension, as the page says.
I feel like everyone missed that.
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.
- 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?
Yes I have. It is not applicable to the scenario I'm after, though in the long term would help the greater Fedora community; including potential users of what could be an extended life cycle.
- 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?
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 - 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
- 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?
-- Jeroen
On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwen kanarip@kanarip.com wrote:
On Mon, 6 Jul 2009 10:57:34 -0600, Kevin Fenzi kevin@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
On 07/07/2009 01:06 AM, Kevin Fenzi wrote:
On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwenkanarip@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
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?
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
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
Jeroen van Meeuwen (kanarip@kanarip.com) said:
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?
Owners are per prodct, not per product + release combination (as I recall.)
Bill
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 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.
Kind regards,
Jeroen van Meeuwen -kanarip
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).
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
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.
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
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
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?
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
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