On 1/3/07, Dave Jones <davej@xxxxxxxxxx> wrote:
On Wed, Jan 03, 2007 at 11:58:05AM -0500, Luis Villa wrote: > I don't think the need (at least my need) is for a Fedora LTS; I > merely ask for one *stable* release at a time that: > > (1) doesn't get new features/new upstream releases Right now, rebases to newer kernel releases is the single provider of the majority of bugfixes we get reported. If we stopped doing that, we'd pretty much be giving up all hope of fixing kernel bugs. It's already completely out of control (right now ~1000 open bugs), and with the limited resources we have to attack this problem, staying close to upstream so that we can get upstream involvement in fixing bugs is our only hope. Yes, occasionally there are regressions, but tbh these days this happens to a much lesser extent. As an avid bugzilla fan, you might be interested to see the kernel bug count over time - http://people.redhat.com/davej/bugzilla-stats.txt For the last six months, we've made pretty much zero overall progress in reducing the overall count, despite hundreds of bugs being closed. By taking away the ability to move to a new upstream, the number of unfixed bugs will skyrocket. We already get a bad rap from some users who claim the process is = file bug = bug sits there = reaches end of life = closed->nextrelease. This will happen more and more if we stagnate on single versions. Backporting fixes is a *ton* of work. We have a huge team of people who do this exclusively for RHEL, and they don't even get to cover everything, just the bugs deemed important. Fedora gets a *lot* more bugs filed, and has a lot less manpower. It's just a losing proposition from every angle from where I'm sitting.
Kernel, and for slightly different reasons GNOME, are likely exceptions to the rule. (In fact, Ubuntu explicitly exempts both from their no-new-upstream freeze.) Both have extremely active upstream development which includes pretty good QA processes. (Kernel more upstream development and less QA, GNOME less upstream development and better organized QA.) I'm sure there are some other exceptions, and the bar for making new exceptions can be lowered if Fedora has its own pre-release QA mechanism like the testing channel I mentioned. Luis _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
