Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix. There were some multilib compose issues (wrong packages landing in the wrong dirs), some translation files that would cause tracebacks in things like anaconda (whoops), and a fedora-release package that forgot to enable updates (double whoops). For these reasons and a few others, we decided to respin the release candidate tree and push the release date out another couple of days.
The current plan is to spin a release candidate this evening with some last minute fixes, and start the sync. Validation has gone very well up to this point and baring any blow ups in the spin process, the release looks very solid. We're planning to release on Thursday Oct 19th. This should give the mirrors enough days to sync up. If things blow up horribly and we have to spin again tomorrow, depending on what time we have to respin we may slip until next week, as releasing on Fridays or Mondays gets you the wrath of the mirror admins (:
I want to thank you all for playing along and helping us to make FC6 the best release yet!
On Mon, 2006-10-16 at 17:26 -0400, Jesse Keating wrote:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix. There were some multilib compose issues (wrong packages landing in the wrong dirs), some translation files that would cause tracebacks in things like anaconda (whoops), and a fedora-release package that forgot to enable updates (double whoops). For these reasons and a few others, we decided to respin the release candidate tree and push the release date out another couple of days.
The current plan is to spin a release candidate this evening with some last minute fixes, and start the sync. Validation has gone very well up to this point and baring any blow ups in the spin process, the release looks very solid. We're planning to release on Thursday Oct 19th. This should give the mirrors enough days to sync up. If things blow up horribly and we have to spin again tomorrow, depending on what time we have to respin we may slip until next week, as releasing on Fridays or Mondays gets you the wrath of the mirror admins (:
Does this mean, that the respin will consist of what is currently in rawhide as of today (10/16)?
Or what is currently frozen, and just that tree there will be fixes and *that* is what is respun? (In other words, if I had did an install test from rawhide over the weekend, would I be ahead of the game or even with FC6 release?)
On Monday 16 October 2006 17:35, Mike Chambers wrote:
Does this mean, that the respin will consist of what is currently in rawhide as of today (10/16)?
I'm waiting on a kernel package to build, which will make the final tree. That should be the only difference between today's rawhide and the final tree.
Or what is currently frozen, and just that tree there will be fixes and *that* is what is respun? (In other words, if I had did an install test from rawhide over the weekend, would I be ahead of the game or even with FC6 release?)
You'll be slightly behind.
Jesse Keating <jkeating <at> redhat.com> writes:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix.
And given that you mentioned that a kernel rebuild is pending, I'm guessing that ext3 corruption problem has been dealt with, right?
I remember Dave Jones saying that he isn't going to push 2.6.18 to FC5 unless that's addressed, so I'm assuming the 2200 has the fix as well.
-- Bojan
On Tue, Oct 17, 2006 at 01:05:35AM +0000, Bojan Smojver wrote:
Jesse Keating <jkeating <at> redhat.com> writes:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix.
And given that you mentioned that a kernel rebuild is pending, I'm guessing that ext3 corruption problem has been dealt with, right?
That's nailed. It only affects filesystems created with a 1K blocksize. (Which by default, we don't do). There was a problem with anaconda at some point during FC6-test where it *would* create them in some situations, but that has been addressed.
So unless you're manually making 1K filesystems with mkfs, you wouldn't have been bitten by this. Just to be sure, the fix got checked into the final FC6 kernel this morning.
I remember Dave Jones saying that he isn't going to push 2.6.18 to FC5 unless that's addressed, so I'm assuming the 2200 has the fix as well.
Actually, I just realised it didn't. I'll make sure it gets in the next update. But as I said, it only shows up in certain circumstances, and you really need to hammer the disk with lots of I/O to make it happen.
Dave
Dave Jones <davej <at> redhat.com> writes:
So unless you're manually making 1K filesystems with mkfs, you wouldn't have been bitten by this. Just to be sure, the fix got checked into the final FC6 kernel this morning.
Got a /boot with 1 kB block size on one machine and on another a file system with 2 kB block size. Looking forward to the fixed kernel.
To be sure to be sure :-)
-- Bojan
On Tue, Oct 17, 2006 at 01:49:06AM +0000, Bojan Smojver wrote:
Dave Jones <davej <at> redhat.com> writes:
So unless you're manually making 1K filesystems with mkfs, you wouldn't have been bitten by this. Just to be sure, the fix got checked into the final FC6 kernel this morning.
Got a /boot with 1 kB block size on one machine and on another a file system with 2 kB block size. Looking forward to the fixed kernel.
Interesting. Did anaconda make those that way for you, or did you do that by hand somehow?
To be sure to be sure :-)
I'll be amazed if you manage to hit this bug in that scenario. After booting, /boot is rarely read again, and this needs gigs and gigs of I/O. It took several hours to trigger on my test box with really fast disks.
Dave
Dave Jones <davej <at> redhat.com> writes:
Interesting. Did anaconda make those that way for you, or did you do that by hand somehow?
The 2 kB block size I picked myself manually, as this file system needed to waste a little bit less space (lots of relatively small files). The 1 kB block size on /boot I can't remember. That machine has been upgraded many, many times, all the way from Red Hat Linux 5.
I'll be amazed if you manage to hit this bug in that scenario. After booting, /boot is rarely read again, and this needs gigs and gigs of I/O. It took several hours to trigger on my test box with really fast disks.
Cool, thanks.
-- Bojan
On Tue, Oct 17, 2006 at 02:50:58 +0000, Bojan Smojver bojan@rexursive.com wrote:
Dave Jones <davej <at> redhat.com> writes:
Interesting. Did anaconda make those that way for you, or did you do that by hand somehow?
The 2 kB block size I picked myself manually, as this file system needed to waste a little bit less space (lots of relatively small files). The 1 kB block size on /boot I can't remember. That machine has been upgraded many, many times, all the way from Red Hat Linux 5.
After seeing this thread I checked and I have 1K block sizes on two machines running FC5. I think one was an upgrade from FC4 and the other was a clean install of FC5.
Once upon a time, Dave Jones davej@redhat.com said:
On Tue, Oct 17, 2006 at 01:49:06AM +0000, Bojan Smojver wrote:
Got a /boot with 1 kB block size on one machine and on another a file system with 2 kB block size. Looking forward to the fixed kernel.
Interesting. Did anaconda make those that way for you, or did you do that by hand somehow?
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda.
On Tuesday 17 October 2006 05:12, Chris Adams wrote:
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda.
My FC5 /boot (100M) has also 1K block size from anaconda. But it is only ext2, do not know, whether or not this is relevant.
Regards, Till
On Tue, Oct 17, 2006 at 09:18:02AM +0200, Till Maas wrote:
On Tuesday 17 October 2006 05:12, Chris Adams wrote:
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda.
My FC5 /boot (100M) has also 1K block size from anaconda. But it is only ext2, do not know, whether or not this is relevant.
The problem only affected ext3 (well, jbd actually).
Dave
Seriously, I believe this is a big issue. Let me summarize:
a) there was a kernel update for FC5 b) this kernel has a known bug which could results in corrupting ext3 filesystems with 1k block size under heavy load c) ... nevertheless it has been pushed out with no special warning d) pratically all /boot partitions are ext3 1k (anaconda generated) e) many partitions on old machine upgraded from previous versions are ext3 1k as well f) experienced users could have much bigger partitions manually generated with 1k block size for their own fun/reasons/optimization (I personally have counted already 400 GBytes of 1k, ext3, partitions just on my personal laptop, desktop and associated backup disks excluding /boot ones). In my case, most of the 1k partitions are such because they are subject to heavy loads with many small files
What was the rationale for releasing an official kernel update under such dangerous conditions? Just "anaconda doesn't generate 1k partitions (not true BTW)"? I still believe Linux is not (yet) Windows and if features are in the system (like 1k blocksize partitions) people can use them if they feel appropriate and they must work. Or perhaps there was a rush to push this 2.6.18 kernel out to get some extra guinea pigs finding all residual bugs? But this could be fair for the FC6 betas, not for FC5 where people is expecting reasonable stability, anyway no life-threatening issue like a (known) filesystem corruption bug.
Now how long do we have to wait before we have an update for FC5 fixing this critical issue? Or do we have to manually rollback kernels on all machines?
Alfredo
On Tue, 17 Oct 2006, Dave Jones wrote:
On Tue, Oct 17, 2006 at 09:18:02AM +0200, Till Maas wrote:
On Tuesday 17 October 2006 05:12, Chris Adams wrote:
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda.
My FC5 /boot (100M) has also 1K block size from anaconda. But it is only ext2, do not know, whether or not this is relevant.
The problem only affected ext3 (well, jbd actually).
Dave
On Wed, Oct 18, 2006 at 12:05:14AM +0200, Alfredo Ferrari wrote:
Seriously, I believe this is a big issue. Let me summarize:
a) there was a kernel update for FC5 b) this kernel has a known bug which could results in corrupting ext3 filesystems with 1k block size under heavy load
it doesn't corrupt filesystems, it crashes instantly when the bug is hit.
c) ... nevertheless it has been pushed out with no special warning d) pratically all /boot partitions are ext3 1k (anaconda generated) e) many partitions on old machine upgraded from previous versions are ext3 1k as well
/boot partitions don't see anywhere near the sustained IO that is needed to hit this bug. it takes _hours_ of insane amounts of IO to hit it. It should be noted that I was the only person to ever see this. No bugzilla reports. No upstream reports. This is a real corner case scenario, as usually filesystems that see that kind of IO want the higher throughput that a larger blocksize brings.
What was the rationale for releasing an official kernel update under such dangerous conditions? Just "anaconda doesn't generate 1k partitions (not true BTW)"? I still believe Linux is not (yet) Windows and if features are in the system (like 1k blocksize partitions) people can use them if they feel appropriate and they must work. Or perhaps there was a rush to push this 2.6.18 kernel out to get some extra guinea pigs finding all residual bugs? But this could be fair for the FC6 betas, not for FC5 where people is expecting reasonable stability, anyway no life-threatening issue like a (known) filesystem corruption bug.
That code hasn't changed in months, so the 2.6.17 kernel in FC5 likely was already affected by the same bug, and yet despite this, no-one was hitting it because of the pathalogical circumstances needed to hit it.
Now how long do we have to wait before we have an update for FC5 fixing this critical issue? Or do we have to manually rollback kernels on all machines?
I'm already working on the next update.
Dave
Thanks Dave
I really appreciated. Knowing that the bug was already there in the previous kernels makes things somewhat better. Despite our 1k partitions are often under heavy loads, apparently we never met it. Also knowing a crash rather than a filesystem corruption would occur is somewhat reassuring (in a relative sense of course)
Obviously I am perfectly aware that you have a lot of work (and you are always answering on these list), sorry for my screaming, but I felt scared by the perspective of corrupting whole filesystems.
Alfredo
On Tue, 17 Oct 2006, Dave Jones wrote:
On Wed, Oct 18, 2006 at 12:05:14AM +0200, Alfredo Ferrari wrote:
Seriously, I believe this is a big issue. Let me summarize:
a) there was a kernel update for FC5 b) this kernel has a known bug which could results in corrupting ext3 filesystems with 1k block size under heavy load
it doesn't corrupt filesystems, it crashes instantly when the bug is hit.
c) ... nevertheless it has been pushed out with no special warning d) pratically all /boot partitions are ext3 1k (anaconda generated) e) many partitions on old machine upgraded from previous versions are ext3 1k as well
/boot partitions don't see anywhere near the sustained IO that is needed to hit this bug. it takes _hours_ of insane amounts of IO to hit it. It should be noted that I was the only person to ever see this. No bugzilla reports. No upstream reports. This is a real corner case scenario, as usually filesystems that see that kind of IO want the higher throughput that a larger blocksize brings.
What was the rationale for releasing an official kernel update under such dangerous conditions? Just "anaconda doesn't generate 1k partitions (not true BTW)"? I still believe Linux is not (yet) Windows and if features are in the system (like 1k blocksize partitions) people can use them if they feel appropriate and they must work. Or perhaps there was a rush to push this 2.6.18 kernel out to get some extra guinea pigs finding all residual bugs? But this could be fair for the FC6 betas, not for FC5 where people is expecting reasonable stability, anyway no life-threatening issue like a (known) filesystem corruption bug.
That code hasn't changed in months, so the 2.6.17 kernel in FC5 likely was already affected by the same bug, and yet despite this, no-one was hitting it because of the pathalogical circumstances needed to hit it.
Now how long do we have to wait before we have an update for FC5 fixing this critical issue? Or do we have to manually rollback kernels on all machines?
I'm already working on the next update.
Dave
On Wed, Oct 18, 2006 at 12:45:25AM +0200, Alfredo Ferrari wrote:
I really appreciated. Knowing that the bug was already there in the previous kernels makes things somewhat better. Despite our 1k partitions are often under heavy loads, apparently we never met it. Also knowing a crash rather than a filesystem corruption would occur is somewhat reassuring (in a relative sense of course)
Obviously I am perfectly aware that you have a lot of work (and you are always answering on these list), sorry for my screaming, but I felt scared by the perspective of corrupting whole filesystems.
The length of time between now and the next update shouldn't be as long as the previous one. Right now I'm killing off some of the low-hanging fruit bugs that there are already patches for or easy fixes, as well as trying to root cause a number of problems that seem to have bitten several users with this update.
Most noticable so far: - There seems to be some oddness in SATA (ata_piix only maybe?) with timeouts. - Upgrades to RAID5 are broken. (This needs an mkinitrd update). - Xen is broken (Needs userspace update).
Despite this, we seem to be making some progress at least. Yesterday there were 889 open FC5 kernel bugs. That's down to 836 right now. Still ridiculously high, but it's getting there, slowly. And this is one of those updates that's definitly fixing more than its broken so far :)
The tough part has been weeding out all the stale old bugs that got migrated over from FC4 from the persistent bugs. Yesterdays mass NEEDINFO should help to sort those out. On Nov 1st if any of those are still NEEDINFO I'll close them.
Dave
Dave Jones wrote:
Most noticable so far:
- There seems to be some oddness in SATA (ata_piix only maybe?) with timeouts.
does this happen with the ahci driver too? on my laptop(ICH7) I can put the controller in the ahci mode but afaik this wasn't supported with 2.6.17 did this code hit 2.6.18 or is it in .19-rcX ?
On Mon, 2006-10-16 at 22:12 -0500, Chris Adams wrote:
Once upon a time, Dave Jones davej@redhat.com said:
On Tue, Oct 17, 2006 at 01:49:06AM +0000, Bojan Smojver wrote:
Got a /boot with 1 kB block size on one machine and on another a file system with 2 kB block size. Looking forward to the fixed kernel.
Interesting. Did anaconda make those that way for you, or did you do that by hand somehow?
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda. --
Same here. FC5, Anaconda built, running on a software RAID1.
- Gilboa
On 10/17/06, Chris Adams cmadams@hiwaay.net wrote:
I just checked an FC5 system, and /boot (at 100M) has a 1K block size. Looking at a rawhide install I did about a week ago, its /boot (100M) also has a 1K block size. These are from anaconda.
How do you check the block size?
Just wondering, n0dalus.
On 10/17/06, Till Maas opensource@till.name wrote:
As root: # tune2fs -l /dev/hda1| grep Block\ size
Thanks. For what it's worth, all four of the /boot partitions I have on computers around here have 1K block sizes.
n0dalus.
On 17/10/06, n0dalus n0dalus+redhat@gmail.com wrote:
On 10/17/06, Till Maas opensource@till.name wrote:
As root: # tune2fs -l /dev/hda1| grep Block\ size
Thanks. For what it's worth, all four of the /boot partitions I have on computers around here have 1K block sizes.
Here too, on four FC5 machines. On all machines, the boot partition was formatted during install, so it definately originates from FC5 Anaconda.
Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 17/10/06, n0dalus n0dalus+redhat@gmail.com wrote:
On 10/17/06, Till Maas opensource@till.name wrote:
As root: # tune2fs -l /dev/hda1| grep Block\ size
Thanks. For what it's worth, all four of the /boot partitions I have on computers around here have 1K block sizes.
Here too, on four FC5 machines. On all machines, the boot partition was formatted during install, so it definately originates from FC5 Anaconda.
Same here (originated from FC5, then moved ro rawhide)
AAAAAAAAAAAAAAARRRRRRRRGGGGGGGGHHHHHHHHH??
Are you telling us (We have lot of filesystems with a 1k blocksize) that the kernel update for FC5 just issued and dutifully installed on all our systems (including a 100 CPU cluster) has "ONLY" this minor bug that it can destroy a fair fraction of our filesystems?
Are you really meaning this??? I hope I completely misunderstood
An astonished (ex)loyal user since RedHat4.2
Alfredo
On Mon, 16 Oct 2006, Dave Jones wrote:
On Tue, Oct 17, 2006 at 01:05:35AM +0000, Bojan Smojver wrote:
Jesse Keating <jkeating <at> redhat.com> writes:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix.
And given that you mentioned that a kernel rebuild is pending, I'm guessing that ext3 corruption problem has been dealt with, right?
That's nailed. It only affects filesystems created with a 1K blocksize. (Which by default, we don't do). There was a problem with anaconda at some point during FC6-test where it *would* create them in some situations, but that has been addressed.
So unless you're manually making 1K filesystems with mkfs, you wouldn't have been bitten by this. Just to be sure, the fix got checked into the final FC6 kernel this morning.
I remember Dave Jones saying that he isn't going to push 2.6.18 to FC5 unless that's addressed, so I'm assuming the 2200 has the fix as well.
Actually, I just realised it didn't. I'll make sure it gets in the next update. But as I said, it only shows up in certain circumstances, and you really need to hammer the disk with lots of I/O to make it happen.
Dave
Alfredo Ferrari (list@pceet030.cern.ch) said:
AAAAAAAAAAAAAAARRRRRRRRGGGGGGGGHHHHHHHHH??
Are you telling us (We have lot of filesystems with a 1k blocksize) that the kernel update for FC5 just issued and dutifully installed on all our systems (including a 100 CPU cluster) has "ONLY" this minor bug that it can destroy a fair fraction of our filesystems?
IIRC, it does not corrupt, it only causes a BUG() (crash).
Bill
On Tuesday 17 October 2006 23:34, Alfredo Ferrari wrote:
our systems (including a 100 CPU cluster) has "ONLY" this minor bug that it can destroy a fair fraction of our filesystems?
I guess it is always only the /boot partition with a 1k block size and it is only ext2 not ext3. Afaik this command # tune2fs -l /dev/hdd1 | grep has_journal produces no output if /dev/hdd1 is an ext2 partition, if you want to test it.
Also the relevant kernel should be fixed. This is how I understand Dave Jones:
"Just to be sure, the fix got checked into the final FC6 kernel this morning."
So there should not be any problem :-)
Regards, Till
As I wrote I have hundreds of GB of 1k, ext3, partitions, not only /boot ones, and we are running FC5 (we need reasonably stable systems) so knowing the FC6 kernel has been fixed this morning is of no help
Alfredo
On Wed, 18 Oct 2006, Till Maas wrote:
On Tuesday 17 October 2006 23:34, Alfredo Ferrari wrote:
our systems (including a 100 CPU cluster) has "ONLY" this minor bug that it can destroy a fair fraction of our filesystems?
I guess it is always only the /boot partition with a 1k block size and it is only ext2 not ext3. Afaik this command # tune2fs -l /dev/hdd1 | grep has_journal produces no output if /dev/hdd1 is an ext2 partition, if you want to test it.
Also the relevant kernel should be fixed. This is how I understand Dave Jones:
"Just to be sure, the fix got checked into the final FC6 kernel this morning."
So there should not be any problem :-)
Regards, Till
On 10/17/06, Alfredo Ferrari list@pceet030.cern.ch wrote:
As I wrote I have hundreds of GB of 1k, ext3, partitions, not only /boot ones, and we are running FC5 (we need reasonably stable systems) so knowing the FC6 kernel has been fixed this morning is of no help
Alfredo
Mistakes happen. Dave is the one kernel guy who is split between multiple packages and reading from his blog has been puking his guts up for the last couple of days.
The issue that I have to always remember, is that this is an operating system that tries to make a reasonably conservative split between cutting edge and conservative choices. Problems like this will occur. You and I, as system administrators, have to manage this risk by putting in change control into the mix..
We shouldn't just update to the latest software on our mission critical software, but use a management process of say 1-2 days before putting newer kernels etc onto the systems. Or putting the kernels on our devel systems and putting them through a ringer before putting them on production systems.
Better stick to the "CERN/RHEL" clone "Scientific Linux" then, right? "Fedora" is by no means intended to comply with enterprise requirements. I recommend that you have a look at:
http://fedora.redhat.com/about/rhel.html
which explains the target audience of the respective distributions. "Fedora" is intended for "Early adopters, enthusiasts, developers" ... This should clarify things.
On 10/17/06, Alfredo Ferrari list@pceet030.cern.ch wrote:
^^^^
As I wrote I have hundreds of GB of 1k, ext3, partitions, not only /boot ones, and we are running FC5 (we need reasonably stable systems) so knowing the FC6 kernel has been fixed this morning is of no help
Alfredo
Joachim Frieben wrote:
Better stick to the "CERN/RHEL" clone "Scientific Linux" then, right? "Fedora" is by no means intended to comply with enterprise requirements. I recommend that you have a look at:
http://fedora.redhat.com/about/rhel.html
which explains the target audience of the respective distributions. "Fedora" is intended for "Early adopters, enthusiasts, developers" ... This should clarify things.
It is a deadlock way for Fedora.
"Enthusiasts and developers" means that Fedora will be used on their home computers/laptops etc. only, and *never* used in the production environment. But a lot of critical bugs can be found only by "production usage". If RHEL is based on Fedora, then Fedora must be stable enough for production systems too. Otherwise RHEL people should spent a lot of testing/laboratory etc. work itself, but even such a work does not guarantee that they will catch all the bugs possible...
Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy
Fedora is fine to be used in most production environments and that is not what will opose Fedora and RH-EL. When a company purchases RH-EL that means that it is really interested in getting support, training and all the other services RedHat provides (besides stable OS and applications).
Here in Brazil I´ve been working in environments where RH-EL is used for intensive database applications (Oracle suite) mixed with some fedora servers for DNS and things like that. The advantages in the use of Fedora is that we are able to foresee things that will be available in next releases of RH-EL.
I agree with the fact that using Fedora is important to assure that the RH-EL is stable and performatic.
Regarding to the "ext3/jbd bug", I don´t think it is up for all the fuzz we have seen in this list. It is around for sometime and nobody noticed it. The fact that the issue came to discussion before the release of FC-6 simply shows the commitment of Linux community in not hidding dirty issues under the rugs and that this problem won´t be present in the next release of RH-EL.
Best regards,
Casimiro
2006/10/18, Dmitry Butskoy buc@odusz.so-cdu.ru:
Joachim Frieben wrote:
Better stick to the "CERN/RHEL" clone "Scientific Linux" then, right? "Fedora" is by no means intended to comply with enterprise requirements.
I
recommend that you have a look at:
http://fedora.redhat.com/about/rhel.html
which explains the target audience of the respective distributions.
"Fedora"
is intended for "Early adopters, enthusiasts, developers" ... This should clarify things.
It is a deadlock way for Fedora.
"Enthusiasts and developers" means that Fedora will be used on their home computers/laptops etc. only, and *never* used in the production environment. But a lot of critical bugs can be found only by "production usage". If RHEL is based on Fedora, then Fedora must be stable enough for production systems too. Otherwise RHEL people should spent a lot of testing/laboratory etc. work itself, but even such a work does not guarantee that they will catch all the bugs possible...
Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wednesday 18 October 2006 08:58, Dmitry Butskoy wrote:
"Enthusiasts and developers" means that Fedora will be used on their home computers/laptops etc. only, and *never* used in the production environment. But a lot of critical bugs can be found only by "production usage". If RHEL is based on Fedora, then Fedora must be stable enough for production systems too. Otherwise RHEL people should spent a lot of testing/laboratory etc. work itself, but even such a work does not guarantee that they will catch all the bugs possible...
Let me be perfectly clear here:
FEDORA IS NOT A BETA OF RHEL!!!!!!
Fedora is its OWN project, and the value we get out of Fedora is much more than a beta program for RHEL. We HAVE a beta program for RHEL, and it is NOT Fedora.
That is perfectly understood.
But not being a beta does not mean that it is not an environment for testing new techs that may or may not find their way into RH-EL.
2006/10/18, Jesse Keating jkeating@redhat.com:
On Wednesday 18 October 2006 08:58, Dmitry Butskoy wrote:
"Enthusiasts and developers" means that Fedora will be used on their home computers/laptops etc. only, and *never* used in the production environment. But a lot of critical bugs can be found only by "production usage". If RHEL is based on Fedora, then Fedora must be stable enough for production systems too. Otherwise RHEL people should spent a lot of testing/laboratory etc. work itself, but even such a work does not guarantee that they will catch all the bugs possible...
Let me be perfectly clear here:
FEDORA IS NOT A BETA OF RHEL!!!!!!
Fedora is its OWN project, and the value we get out of Fedora is much more than a beta program for RHEL. We HAVE a beta program for RHEL, and it is NOT Fedora.
-- Jesse Keating Release Engineer: Fedora
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Please don't
Top post
It's considered
Bad netiquette [1, 2] >> If not >>>> Plain rude.
- Gilboa
[1] http://fedoraproject.org/wiki/Communicate/MailingListGuidelines?action=show&... [2] http://en.wikipedia.org/wiki/Top-posting
On Wed, 2006-10-18 at 11:57 -0200, casimiro barreto wrote:
That is perfectly understood.
But not being a beta does not mean that it is not an environment for testing new techs that may or may not find their way into RH-EL.
2006/10/18, Jesse Keating < jkeating@redhat.com>: On Wednesday 18 October 2006 08:58, Dmitry Butskoy wrote: > "Enthusiasts and developers" means that Fedora will be used on their > home computers/laptops etc. only, and *never* used in the production > environment. But a lot of critical bugs can be found only by "production > usage". > If RHEL is based on Fedora, then Fedora must be stable enough for > production systems too. Otherwise RHEL people should spent a lot of > testing/laboratory etc. work itself, but even such a work does not > guarantee that they will catch all the bugs possible...
Let me be perfectly clear here: FEDORA IS NOT A BETA OF RHEL!!!!!! Fedora is its OWN project, and the value we get out of Fedora is much more than a beta program for RHEL. We HAVE a beta program for RHEL, and it is NOT Fedora. -- Jesse Keating Release Engineer: Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Lam
understand.
wrong, he won't
the order
You got
Dnia 18-10-2006, śro o godzinie 16:08 +0200, Gilboa Davara napisał(a):
Please don't
Top post
It's considered
> Bad netiquette [1, 2] >>> If not >>>>> Plain rude.
That is perfectly understood.
But not being a beta does not mean that it is not an environment for testing new techs that may or may not find their way into RH-EL.
Nobody will ever deny this, on the contrary: I am sure "Red Hat" and the "Fedora Core" user community welcome if you offer your mission critical systems as guinea pig for testing and debugging "Fedora Core", a certainly honorable and rewarding task. But do not complain if you use "Fedora Core" for enterprise purposes, and some sudden bug eats a chunk of bytes here and there. We had been warned in advance.
On Wed, 18/10/06 14:57 +0100, casimiro barreto wrote:
That is perfectly understood.
But not being a beta does not mean that it is not an environment for testing new techs that may or may not find their way into RH-EL.
If you support Fedora like redhat does, you can test new techs for your product too.
casimiro barreto wrote:
That is perfectly understood.
But not being a beta does not mean that it is not an environment for testing new techs that may or may not find their way into RH-EL.
By that logic, Debian, Ubuntu, OpenSuSE, Slackware, etc. are all test bases for RHEL, because bugs they fix that go upstream all wind up in RHEL eventually. However, you'll be met with equal contempt from people if you go onto those distributions' respective mailing lists and tell them they are just test beds for RHEL. They are completely different distributions with different requirements.
On 18/10/06, Jesse Keating jkeating@redhat.com wrote:
Let me be perfectly clear here:
FEDORA IS NOT A BETA OF RHEL!!!!!!
I think people using Fedora and in anyway involved with it see it that way. However, the CTO of Red Hat doesn't see things that way:
http://www.internetnews.com/dev-news/article.php/3628476
Specifically: "We're convinced that there is a better way to develop software, so what we did is we blew up the notion of an Alpha and we use Fedora as an alpha."
and
"FC 5 and FC6 constituted the role of an alpha and now we're going right to Beta 1 in a few weeks."
I think these quotes don't reflect reality, but it's a very very unfortunate thing to have said - quite damaging to the perception if the project, I think.
Jonathan.
On Thursday 19 October 2006 09:17, Jonathan Underwood wrote:
I think these quotes don't reflect reality, but it's a very very unfortunate thing to have said - quite damaging to the perception if the project, I think.
This was already discussed on the Marketing list, and internally that person has been made aware of how damaging such words are. It is somewhat out of context.
Jonathan Underwood wrote:
I think people using Fedora and in anyway involved with it see it that way. However, the CTO of Red Hat doesn't see things that way:
See the list archives, this horse was beaten beyond death, it was a poor choice of words.
Jonathan Underwood wrote:
On 18/10/06, Jesse Keating jkeating@redhat.com wrote:
Let me be perfectly clear here:
FEDORA IS NOT A BETA OF RHEL!!!!!!
I think people using Fedora and in anyway involved with it see it that way. However, the CTO of Red Hat doesn't see things that way:
http://www.internetnews.com/dev-news/article.php/3628476
Specifically: "We're convinced that there is a better way to develop software, so what we did is we blew up the notion of an Alpha and we use Fedora as an alpha."
and
"FC 5 and FC6 constituted the role of an alpha and now we're going right to Beta 1 in a few weeks."
"Fedora is not a beta of RHEL". Sure! It is an alpha of RHEL :-/
Actually, recently I feel that some RH people think so exactly...
tor, 19 10 2006 kl. 17:29 +0400, skrev Dmitry Butskoy:
Jonathan Underwood wrote:
On 18/10/06, Jesse Keating jkeating@redhat.com wrote:
Let me be perfectly clear here:
FEDORA IS NOT A BETA OF RHEL!!!!!!
I think people using Fedora and in anyway involved with it see it that way. However, the CTO of Red Hat doesn't see things that way:
http://www.internetnews.com/dev-news/article.php/3628476
Specifically: "We're convinced that there is a better way to develop software, so what we did is we blew up the notion of an Alpha and we use Fedora as an alpha."
and
"FC 5 and FC6 constituted the role of an alpha and now we're going right to Beta 1 in a few weeks."
"Fedora is not a beta of RHEL". Sure! It is an alpha of RHEL :-/
Actually, recently I feel that some RH people think so exactly...
So what?
Every distribution that puts out releases is an alpha for RHEL, they just happen like many major Linux deployments to take advantage of the fine work produced by the Fedora Project. RHEL is a derived product of the Fedora platform, just like the One Laptop Per Children OS and the Linux that Yellow Dog is producing to go on every single PS3.
Fedora is a powerful platform, I find it degrading and insulting to the Fedora community that people reduce the fine work to "merely a RHEL beta", if it was that nobody else would use it, yet every major Linux deployment in recent history has been on a Fedora derived system.
What Red Hat calls their niche product in relation to Fedora given their longer development cycle has no baring on the absolutely fantastic OS Fedora gives people for any purpose, be that building their own niche product or installing Fedora on their systems.
- David Nielsen
David Nielsen wrote:
"FC 5 and FC6 constituted the role of an alpha and now we're going right to Beta 1 in a few weeks."
"Fedora is not a beta of RHEL". Sure! It is an alpha of RHEL :-/
Certainly it was a sarcasm...
Fedora is a powerful platform, I find it degrading and insulting to the Fedora community that people reduce the fine work to "merely a RHEL beta",
+1
if it was that nobody else would use it,
Unfortunately such a scenario is really possible. I know a lot of users who had switched to CentOS or similar RHEL-based systems. The main reason is to avoid stability decreasing.
Initially, such users could be good volunteers for Fedora, but it was too hard for them to handle a production system and to fix escalating amount of bugs simultaneously. The "escalating amount of bugs" can be reduced, but only after all RHEL people will really cease to consider Fedora as RHEL-alpha.
~buc
On Wed, Oct 18, 2006 at 16:58:38 +0400, Dmitry Butskoy buc@odusz.so-cdu.ru wrote:
If RHEL is based on Fedora, then Fedora must be stable enough for production systems too. Otherwise RHEL people should spent a lot of testing/laboratory etc. work itself, but even such a work does not guarantee that they will catch all the bugs possible...
The issue is stability in the bug sense, but in the application sense. It is a real pain to have application interfaces changing rapidly on a production system. Fedora changes too rapidly to be desirable for most production uses.
On 10/19/06, Bruno Wolff III bruno@wolff.to wrote:
The issue is stability in the bug sense, but in the application sense. It is a real pain to have application interfaces changing rapidly on a production system. Fedora changes too rapidly to be desirable for most production uses.
Its a side-effect of the very active development being used by open source projects coupled with the popular release early release often model that many individual software projects adhere to. We simply can't have our cake and eat it to. In a world with competing demands for finite developer resources... long-lived interface specs come at a maintainence cost. Inferface instability is the price we all pay for an organic development model. Better interface stability will only come when individual projects decide to make forwards and backwards compatibility a more important priority to use available project resources on. This isn't the sort of thing distributions can enforce on projects without impacting the rate of new technology adoption into the distro.
-jef"In a world filled with nothing but imperfect solutions, to ill-posed problems, a few shots of tequila for breakfast is the only safe bet"spaleta
On 10/17/06, Alfredo Ferrari list@pceet030.cern.ch wrote:
AAAAAAAAAAAAAAARRRRRRRRGGGGGGGGHHHHHHHHH??
Are you telling us (We have lot of filesystems with a 1k blocksize) that the kernel update for FC5 just issued and dutifully installed on all our systems (including a 100 CPU cluster) has "ONLY" this minor bug that it can destroy a fair fraction of our filesystems?
Are you really meaning this??? I hope I completely misunderstood
An astonished (ex)loyal user since RedHat4.2 Alfredo
Interesting tone you use here, esp. considering your asking for help/information. Might want to check that. There is rarely ever a reason to rush to a new kernel on a live production machine IMHO.
On Monday 16 October 2006 17:26, Jesse Keating wrote:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix. There were some multilib compose issues (wrong packages landing in the wrong dirs), some translation files that would cause tracebacks in things like anaconda (whoops), and a fedora-release package that forgot to enable updates (double whoops). For these reasons and a few others, we decided to respin the release candidate tree and push the release date out another couple of days.
The current plan is to spin a release candidate this evening with some last minute fixes, and start the sync. Validation has gone very well up to this point and baring any blow ups in the spin process, the release looks very solid. We're planning to release on Thursday Oct 19th. This should give the mirrors enough days to sync up. If things blow up horribly and we have to spin again tomorrow, depending on what time we have to respin we may slip until next week, as releasing on Fridays or Mondays gets you the wrath of the mirror admins (:
I want to thank you all for playing along and helping us to make FC6 the best release yet!
Hi, its me again, remember me? I was the guy who told you we would probably release on Thursday of this week. Yeah, about that...
Bugs suck. More bugs suck more. I'd rather go DOWN in bug count with the trees we spin than up, so after some regressions popped up, we're going to respin again and push the release out until next Tuesday, the 24th. This will ensure we finish playing whack-a-mole with the tree and we give the mirrors a fighting chance at getting synced up before we open the flood gates.
In the interest of full disclosure (like you couldn't read rawhide report from tomorrow...) the following bugs popped up / were noticed / were introduced / were fixed due to extra time / and have been fixed (hopefully) with the tree I'm spinning, and rawhide that will land tomorrow.
211097: latest rawhide kernel broke xenguest-install / virt-manager 211117: Anaconda traceback + forced reboot when file temporarily unavailable 211118: Unable to connect to xend with xen Dom0 kernel and xend running 209945: s-c-firewall creates unusable default for ipv6 203570: Starting X brings up a blank screen (for mga) <nobug>: coolkey package %post errors <nobug>: classpathx-mail multilib conflicts <nobug>: fedora-release-notes css not optimal for some non-english languages <nobug>: broken deps on x86_64 and ppc(64)
So, provided that we don't introduce any NEW bugs while fixing THOSE bugs, the tree should be golden as of tonight. We'll begin syncing once we've finished smoke testing the tree tomorrow (you can help too on rawhide!). There will also be a fair number of "0 day" updates for FC6, due to the amount of time that we've been frozen and not taking any updates. Many of these will go into updates-testing first, and some testing on those would be good, since they saw 0 rawhide time.
That is all, I now return you to your regularly scheduled mortgage and lottery spam.
Jesse Keating wrote:
On Monday 16 October 2006 17:26, Jesse Keating wrote:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix. There were some multilib compose issues (wrong packages landing in the wrong dirs), some translation files that would cause tracebacks in things like anaconda (whoops), and a fedora-release package that forgot to enable updates (double whoops). For these reasons and a few others, we decided to respin the release candidate tree and push the release date out another couple of days.
The current plan is to spin a release candidate this evening with some last minute fixes, and start the sync. Validation has gone very well up to this point and baring any blow ups in the spin process, the release looks very solid. We're planning to release on Thursday Oct 19th. This should give the mirrors enough days to sync up. If things blow up horribly and we have to spin again tomorrow, depending on what time we have to respin we may slip until next week, as releasing on Fridays or Mondays gets you the wrath of the mirror admins (:
I want to thank you all for playing along and helping us to make FC6 the best release yet!
Hi, its me again, remember me? I was the guy who told you we would probably release on Thursday of this week. Yeah, about that...
Bugs suck. More bugs suck more. I'd rather go DOWN in bug count with the trees we spin than up, so after some regressions popped up, we're going to respin again and push the release out until next Tuesday, the 24th. This
okay then.
my suggestion is: do a complete respin or whatsoever and *then* announce a release date.
just my opinion !
okay ?
...
On Tuesday 17 October 2006 22:14, ronald wrote:
okay then.
my suggestion is: do a complete respin or whatsoever and *then* announce a release date.
just my opinion !
okay ?
We did that. The problem was that initial tests I did showed promising. The problem was that AFTER we started the sync that would go to mirrors some things were caught in regression. This time around all these regressions were tested fixed before we announced, but that doesn't mean some user in some configuration we don't have here could find a showstopper before we send to the mirrors. It is better to be more vocal about whats going on than a black box.
Jesse Keating wrote:
On Monday 16 October 2006 17:26, Jesse Keating wrote:
<snip> Hi, its me again, remember me? I was the guy who told you we would probably release on Thursday of this week. Yeah, about that...
Bugs suck. More bugs suck more. I'd rather go DOWN in bug count with the trees we spin than up, so after some regressions popped up, we're going to respin again and push the release out until next Tuesday, the 24th. This will ensure we finish playing whack-a-mole with the tree and we give the mirrors a fighting chance at getting synced up before we open the flood gates.
In the interest of full disclosure (like you couldn't read rawhide report from tomorrow...) the following bugs popped up / were noticed / were introduced / were fixed due to extra time / and have been fixed (hopefully) with the tree I'm spinning, and rawhide that will land tomorrow.
211097: latest rawhide kernel broke xenguest-install / virt-manager 211117: Anaconda traceback + forced reboot when file temporarily unavailable 211118: Unable to connect to xend with xen Dom0 kernel and xend running 209945: s-c-firewall creates unusable default for ipv6 203570: Starting X brings up a blank screen (for mga) <nobug>: coolkey package %post errors <nobug>: classpathx-mail multilib conflicts <nobug>: fedora-release-notes css not optimal for some non-english languages <nobug>: broken deps on x86_64 and ppc(64)
So, provided that we don't introduce any NEW bugs while fixing THOSE bugs, the tree should be golden as of tonight. We'll begin syncing once we've finished smoke testing the tree tomorrow (you can help too on rawhide!). There will also be a fair number of "0 day" updates for FC6, due to the amount of time that we've been frozen and not taking any updates. Many of these will go into updates-testing first, and some testing on those would be good, since they saw 0 rawhide time.
That is all, I now return you to your regularly scheduled mortgage and lottery spam.
The rawhide tree of 20061017 with kernel-2.6.18-1.2798.fc6 successfully saw all software raid 5 devices and installed nicely via network install. Bz 208947 will be updated after some more testing.
Please let this continue for the FC6 final.
On Tue, 2006-10-17 at 20:07 -0400, Jesse Keating wrote:
There will also be a fair number of "0 day" updates for FC6, due to the amount of time that we've been frozen and not taking any updates. Many of these will go into updates-testing first, and some testing on those would be good, since they saw 0 rawhide time.
The Bluetooth fixes are going straight into updates. They've been available for 3 weeks already from http://david.woodhou.se/bluez/ and really should have been in FC6.
Out of interest, other packages updated in FC6 since I was told that it was far too late to destabilise FC6 by introducing the fixed packages are as follows:
Sep 28 11:03 fonts-sinhala-0.2.1-1.src.rpm Sep 28 12:35 coreutils-5.97-11.src.rpm Sep 28 12:40 gimp-print-4.2.7-22.src.rpm Sep 28 13:23 pam-0.99.6.2-3.fc6.src.rpm Sep 28 14:08 scim-sinhala-0.2.0-2.fc6.src.rpm Sep 28 14:42 perl-Net-DNS-0.59-1.fc6.src.rpm Sep 28 15:06 libsepol-1.12.27-1.src.rpm Sep 28 17:18 mkinitrd-5.1.19-1.src.rpm Sep 28 19:05 openais-0.80.1-3.src.rpm Sep 28 20:14 lvm2-2.02.06-4.src.rpm Sep 28 21:56 kdeutils-3.5.4-5.fc6.src.rpm Sep 28 22:35 ifd-egate-0.05-15.src.rpm Sep 28 23:22 sip-4.4.5-3.src.rpm Sep 29 03:06 vim-7.0.109-3.src.rpm Sep 29 07:33 ttmkfdir-3.0.9-22.src.rpm Sep 29 10:29 fonts-indic-2.0.6-1.src.rpm Sep 29 11:28 kbd-1.12-18.src.rpm Sep 29 12:28 anacron-2.3-41.fc6.src.rpm Sep 29 12:59 scim-bridge-0.4.5-3.fc6.src.rpm Sep 29 14:25 checkpolicy-1.30.12-1.src.rpm Sep 29 15:50 hplip-1.6.7-4.src.rpm Sep 29 15:58 libsemanage-1.6.17-1.src.rpm Sep 29 18:35 eclipse-bugzilla-0.2.4-3.fc6.src.rpm Sep 29 18:42 paps-0.6.6-16.fc6.src.rpm Sep 29 19:50 policycoreutils-1.30.30-1.src.rpm Sep 29 19:52 dhcdbd-2.1-1.fc6.src.rpm Sep 29 20:00 virt-manager-0.2.3-2.fc6.src.rpm Sep 29 20:01 dhcpv6-0.10-32.fc6.src.rpm Sep 29 20:08 perl-DBD-MySQL-3.0007-1.fc6.src.rpm Sep 29 20:31 eclipse-changelog-2.3.2-1.fc6.src.rpm Sep 29 20:32 eclipse-cdt-3.1.1-1.fc6.src.rpm Sep 29 20:51 perl-Archive-Tar-1.30-1.fc6.src.rpm Sep 29 21:08 control-center-2.16.0-9.fc6.src.rpm Sep 29 21:20 cyrus-sasl-2.1.22-4.src.rpm Sep 29 21:36 audit-1.2.8-1.fc6.src.rpm Sep 30 05:06 ekiga-2.0.2-7.src.rpm Sep 30 12:22 bluez-libs-3.7-1.src.rpm Sep 30 13:58 gtk2-2.10.4-4.fc6.src.rpm Sep 30 22:08 mesa-6.5.1-7.fc6.src.rpm Sep 30 22:36 libX11-1.0.3-4.fc6.src.rpm Oct 1 05:09 gcalctool-5.8.24-2.fc6.src.rpm Oct 1 08:52 eclipse-3.2.1-4.fc6.src.rpm Oct 1 19:55 valgrind-3.2.1-4.src.rpm Oct 1 20:21 a2ps-4.13b-57.src.rpm Oct 1 20:22 gzip-1.3.5-9.src.rpm Oct 1 20:23 grub-0.97-13.src.rpm Oct 1 20:24 gnome-user-share-0.10-5.src.rpm Oct 1 20:24 libunwind-0.98.5-3.src.rpm Oct 1 20:25 ipsec-tools-0.6.5-6.src.rpm Oct 1 20:27 libgpg-error-1.4-2.src.rpm Oct 1 20:28 kudzu-1.2.57.1-2.src.rpm Oct 1 20:29 jessie-1.0.1-7.src.rpm Oct 1 20:31 libselinux-1.30.29-2.src.rpm Oct 1 20:32 logrotate-3.7.4-7.src.rpm Oct 1 20:32 libXp-1.0.0-8.src.rpm Oct 1 20:33 libuser-0.54.7-2.src.rpm Oct 1 20:34 mod_auth_kerb-5.1-3.src.rpm Oct 1 20:35 ncompress-4.2.4-47.src.rpm Oct 1 20:36 icu-3.6-4.src.rpm Oct 1 20:37 mailman-2.1.9-2.src.rpm Oct 1 20:37 pam_pkcs11-0.5.3-22.src.rpm Oct 1 20:39 ppc64-utils-0.9-15.src.rpm Oct 1 20:39 readahead-1.3-5.src.rpm Oct 1 20:42 squashfs-tools-3.0-4.src.rpm Oct 1 20:43 sudo-1.6.8p12-10.src.rpm Oct 1 20:45 wget-1.10.2-7.src.rpm Oct 1 20:46 xinetd-2.3.14-8.src.rpm Oct 1 20:56 openldap-2.3.27-4.src.rpm Oct 1 21:18 cachefilesd-0.7-2.fc6.src.rpm Oct 1 21:19 cman-2.0.18-2.fc6.src.rpm Oct 1 21:21 beagle-0.2.10-3.fc6.src.rpm Oct 1 21:21 dbus-0.93-3.fc6.src.rpm Oct 1 21:22 desktop-printing-0.19-16.fc6.src.rpm Oct 1 21:28 dovecot-1.0-0.1.rc7.fc6.src.rpm Oct 1 21:29 evince-0.6.0-3.fc6.src.rpm Oct 1 21:33 gsf-sharp-0.8.1-2.fc6.src.rpm Oct 1 21:35 evolution-connector-2.8.0-3.fc6.src.rpm Oct 1 21:37 fontconfig-2.4.1-3.fc6.src.rpm Oct 1 21:44 gnome-applets-2.16.0.1-7.fc6.src.rpm Oct 1 21:45 gnome-python2-extras-2.14.2-4.fc6.src.rpm Oct 1 21:46 gnome-screensaver-2.16.0-7.fc6.src.rpm Oct 1 21:47 esc-1.0.0-16.fc6.src.rpm Oct 1 21:54 gnome-vfs2-2.16.0-4.fc6.src.rpm Oct 1 21:55 iproute-2.6.16-6.fc6.src.rpm Oct 1 21:56 evolution-2.8.0-7.fc6.src.rpm Oct 1 21:58 pyxf86config-0.3.31-2.fc6.src.rpm Oct 1 21:58 jakarta-commons-codec-1.3-7jpp.2.src.rpm Oct 1 22:01 libgnome-2.16.0-4.fc6.src.rpm Oct 1 22:05 libgtop2-2.14.4-2.fc6.src.rpm Oct 1 22:06 libsoup-2.2.96-4.fc6.src.rpm Oct 1 22:07 libgnomeui-2.16.0-4.fc6.src.rpm Oct 1 22:10 libwnck-2.16.0-4.fc6.src.rpm Oct 1 22:10 xorg-x11-drv-vesa-1.2.1-4.src.rpm Oct 1 22:11 mc-4.6.1a-30.fc6.src.rpm Oct 1 22:12 xorg-x11-drv-i810-1.6.5-9.fc6.src.rpm Oct 1 22:12 kdelibs-3.5.4-10.fc6.src.rpm Oct 1 22:13 nc-1.84-10.fc6.src.rpm Oct 1 22:14 metacity-2.16.0-5.fc6.src.rpm Oct 1 22:19 orca-1.0.0-4.fc6.src.rpm Oct 1 22:20 pango-1.14.4-3.fc6.src.rpm Oct 1 22:20 nautilus-2.16.0-5.fc6.src.rpm Oct 1 22:26 net-snmp-5.3.1-11.fc6.src.rpm Oct 1 22:27 poppler-0.5.4-2.fc6.src.rpm Oct 1 22:28 redhat-lsb-3.1-11.src.rpm Oct 1 22:32 scim-chewing-0.3.1-7.fc6.src.rpm Oct 1 22:34 scim-anthy-1.2.0-3.fc6.src.rpm Oct 1 22:37 python-2.4.3-18.fc6.src.rpm Oct 1 22:40 tsclient-0.148-4.fc6.src.rpm Oct 1 22:41 ruby-1.8.5-3.fc6.src.rpm Oct 1 22:46 xorg-x11-drv-sis-0.9.1-7.src.rpm Oct 1 22:49 xorg-x11-xinit-1.0.2-12.fc6.src.rpm Oct 1 22:49 xorg-x11-proto-devel-7.1-9.fc6.src.rpm Oct 1 23:08 tetex-3.0-32.fc6.src.rpm Oct 1 23:59 kdebase-3.5.4-12.fc6.src.rpm Oct 2 08:19 alsa-utils-1.0.12-3.fc6.src.rpm Oct 2 08:49 openssl-0.9.8b-8.src.rpm Oct 2 09:07 gettext-0.14.6-3.fc6.src.rpm Oct 2 09:18 openssl097a-0.9.7a-9.src.rpm Oct 2 10:19 squid-2.6.STABLE4-1.fc6.src.rpm Oct 2 15:09 libpng-1.2.10-7.src.rpm Oct 2 15:34 xorg-x11-drv-ati-6.6.2-4.fc6.src.rpm Oct 2 15:46 xsane-0.991-2.fc6.src.rpm Oct 2 15:59 netpbm-10.35-6.fc6.src.rpm Oct 2 16:07 scim-1.4.4-35.fc6.src.rpm Oct 2 16:10 system-config-printer-0.7.32-1.src.rpm Oct 2 16:16 frysk-0.0.1.2006.10.02.rh1-1.fc6.src.rpm Oct 2 16:32 im-chooser-0.3.3-2.fc6.src.rpm Oct 2 17:29 firstboot-1.4.23-1.src.rpm Oct 2 17:41 openssh-4.3p2-10.src.rpm Oct 2 18:14 pygtk2-2.10.1-4.fc6.src.rpm Oct 2 18:53 libgnomecups-0.2.2-8.src.rpm Oct 2 19:42 xorg-x11-apps-7.1-3.fc6.src.rpm Oct 2 19:51 xorg-x11-drv-via-0.2.1-7.src.rpm Oct 2 19:59 amanda-2.5.0p2-4.src.rpm Oct 2 20:21 pyspi-0.6.0-2.fc6.src.rpm Oct 2 21:26 libvirt-0.1.7-2.src.rpm Oct 2 22:19 compiz-0.0.13-0.32.20060817git.fc6.src.rpm Oct 2 22:22 bluez-hcidump-1.32-1.src.rpm Oct 3 07:10 nautilus-cd-burner-2.16.0-3.fc6.src.rpm Oct 3 08:53 tclx-8.4.0-5.fc6.src.rpm Oct 3 09:08 usermode-1.87-3.src.rpm Oct 3 14:40 specspo-12-1.src.rpm Oct 3 15:15 perl-5.8.8-10.src.rpm Oct 3 19:55 setroubleshoot-1.0-1.src.rpm Oct 3 20:00 iscsi-initiator-utils-6.2.0.695-0.5.src.rpm Oct 4 07:41 libsilc-1.0.2-2.fc6.src.rpm Oct 4 09:39 rsh-0.17-36.src.rpm Oct 4 10:15 tar-1.15.1-19.src.rpm Oct 4 14:33 system-config-network-1.3.95-1.src.rpm Oct 4 15:25 php-5.1.6-3.src.rpm Oct 4 18:36 gnome-icon-theme-2.16.0.1-2.fc6.src.rpm Oct 4 18:55 gnome-power-manager-2.16.0-3.fc6.src.rpm Oct 4 20:38 parted-1.7.1-16.fc6.src.rpm Oct 4 20:51 hal-0.5.8.1-4.fc6.src.rpm Oct 4 21:31 pyparted-1.7.3-2.fc6.src.rpm Oct 4 22:04 xen-3.0.2-44.src.rpm Oct 5 04:17 xorg-x11-server-1.1.1-47.fc6.src.rpm Oct 5 13:34 cairo-java-1.0.5-3.fc6.src.rpm Oct 5 14:36 gaim-2.0.0-0.15.beta3.fc6.src.rpm Oct 5 15:45 cups-1.2.4-9.src.rpm Oct 5 16:21 libgtk-java-2.8.6-4.fc6.src.rpm Oct 5 16:41 libgnome-java-2.12.4-3.fc6.src.rpm Oct 5 17:14 libvte-java-0.12.1-4.fc6.src.rpm Oct 5 17:39 libgconf-java-2.12.4-4.fc6.src.rpm Oct 5 17:42 libglade-java-2.12.5-3.fc6.src.rpm Oct 5 17:59 glib-java-0.2.6-3.fc6.src.rpm Oct 5 22:05 gjdoc-0.7.7-11.src.rpm Oct 6 20:42 authconfig-5.3.10-1.src.rpm Oct 6 22:57 openoffice.org-2.0.4-5.3.src.rpm Oct 7 09:22 autofs-5.0.1-0.rc2.10.src.rpm Oct 8 16:23 glibc-2.5-3.src.rpm Oct 9 01:44 thunderbird-1.5.0.7-4.fc6.src.rpm Oct 9 15:02 hwdata-0.191-1.src.rpm Oct 9 20:55 fedora-release-notes-6-2.src.rpm Oct 9 22:45 coolkey-1.0.1-9.src.rpm Oct 10 04:36 acpid-1.0.4-5.src.rpm Oct 10 10:58 tzdata-2006m-2.fc6.src.rpm Oct 10 18:44 java-1.4.2-gcj-compat-1.4.2.0-40jpp.110.src.rpm Oct 10 22:06 filesystem-2.4.0-1.src.rpm Oct 10 22:14 device-mapper-1.02.07-3.src.rpm Oct 11 06:54 udev-095-14.src.rpm Oct 11 09:37 elinks-0.11.1-5.src.rpm Oct 11 15:03 libiec61883-1.0.0-11.fc6.src.rpm Oct 11 15:19 system-config-boot-0.2.12-1.src.rpm Oct 11 16:08 setup-2.5.55-1.src.rpm Oct 11 17:42 gcc-4.1.1-30.src.rpm Oct 11 19:07 hsqldb-1.8.0.4-3jpp.4.src.rpm Oct 11 20:04 dmraid-1.0.0.rc13-1.fc6.src.rpm Oct 11 20:35 booty-0.80-1.src.rpm Oct 11 22:05 python-pyblock-0.24-2.src.rpm Oct 11 23:44 firefox-1.5.0.7-7.fc6.src.rpm Oct 12 03:55 initscripts-8.45.3-1.src.rpm Oct 12 10:16 util-linux-2.13-0.44.fc6.src.rpm Oct 12 13:30 rhgb-0.16.4-1.fc6.src.rpm Oct 12 15:13 mono-1.1.17.1-3.fc6.src.rpm Oct 12 15:52 selinux-policy-2.3.18-10.src.rpm Oct 12 17:41 devhelp-0.12-6.fc6.src.rpm Oct 12 17:48 yelp-2.16.0-4.fc6.src.rpm Oct 12 18:41 epiphany-2.16.0-4.fc6.src.rpm Oct 13 00:23 kernel-2.6.18-1.2784.fc6.src.rpm Oct 13 02:32 anaconda-11.1.1.2-1.src.rpm Oct 13 02:36 pirut-1.2.5-1.src.rpm Oct 13 04:14 python-virtinst-0.95.0-1.fc6.src.rpm Oct 13 12:12 sane-backends-1.0.18-5.fc6.src.rpm Oct 13 13:33 yum-3.0-6.src.rpm Oct 13 13:45 mdadm-2.5.4-2.fc6.src.rpm Oct 13 14:44 lam-7.1.2-8.fc6.src.rpm Oct 13 16:31 autoconf-2.59-12.src.rpm Oct 13 18:19 SysVinit-2.86-14.src.rpm Oct 13 18:51 openmpi-1.1-7.fc6.src.rpm Oct 13 21:39 rhpxl-0.39-2.src.rpm Oct 13 21:43 rhpl-0.194-1.src.rpm Oct 13 21:47 pykickstart-0.36-1.src.rpm Oct 13 21:59 system-config-keyboard-1.2.10-2.src.rpm Oct 13 22:12 system-config-date-1.8.7-1.src.rpm
On Wednesday 18 October 2006 06:43, David Woodhouse wrote:
Out of interest, other packages updated in FC6 since I was told that it was far too late to destabilise FC6 by introducing the fixed packages are as follows:
A good chunk of these were multilib conflict fixes, a few security fixes, and quite a few actual bug fixes. Hardly any should have been new features or 3+ months of pent up changes suddenly released into a package. Each update was evaluated on a case by case basis for change, impact, and what would happen if we left it out.
On Tue, 2006-10-17 at 20:07 -0400, Jesse Keating wrote:
Hi, its me again, remember me? I was the guy who told you we would probably release on Thursday of this week. Yeah, about that...
Hi Jesse,
I appreciate the status updates on FC6. Would be prudent to post at least a condensed version of these announcements to fedora-announce-list so that they get more visibility? Especially when the announcement is about a schedule slip.
Matthew Barnes
On Wednesday 18 October 2006 11:48, Matthew Barnes wrote:
I appreciate the status updates on FC6. Would be prudent to post at least a condensed version of these announcements to fedora-announce-list so that they get more visibility? Especially when the announcement is about a schedule slip.
It was sent to announce-list...
On Monday 16 October 2006 17:26, Jesse Keating wrote:
Over the weekend we ran into a few more bugs with Fedora Core 6 that we decided were important enough to fix. There were some multilib compose issues (wrong packages landing in the wrong dirs), some translation files that would cause tracebacks in things like anaconda (whoops), and a fedora-release package that forgot to enable updates (double whoops). For these reasons and a few others, we decided to respin the release candidate tree and push the release date out another couple of days.
The current plan is to spin a release candidate this evening with some last minute fixes, and start the sync. Validation has gone very well up to this point and baring any blow ups in the spin process, the release looks very solid. We're planning to release on Thursday Oct 19th. This should give the mirrors enough days to sync up. If things blow up horribly and we have to spin again tomorrow, depending on what time we have to respin we may slip until next week, as releasing on Fridays or Mondays gets you the wrath of the mirror admins (:
I want to thank you all for playing along and helping us to make FC6 the best release yet!
Hi, its me again, remember me? I was the guy who told you we would probably release on Thursday of this week. Yeah, about that...
Bugs suck. More bugs suck more. I'd rather go DOWN in bug count with the trees we spin than up, so after some regressions popped up, we're going to respin again and push the release out until next Tuesday, the 24th. This will ensure we finish playing whack-a-mole with the tree and we give the mirrors a fighting chance at getting synced up before we open the flood gates.
In the interest of full disclosure (like you couldn't read rawhide report from tomorrow...) the following bugs popped up / were noticed / were introduced / were fixed due to extra time / and have been fixed (hopefully) with the tree I'm spinning, and rawhide that will land tomorrow.
211097: latest rawhide kernel broke xenguest-install / virt-manager 211117: Anaconda traceback + forced reboot when file temporarily unavailable 211118: Unable to connect to xend with xen Dom0 kernel and xend running 209945: s-c-firewall creates unusable default for ipv6 203570: Starting X brings up a blank screen (for mga) <nobug>: coolkey package %post errors <nobug>: classpathx-mail multilib conflicts <nobug>: fedora-release-notes css not optimal for some non-english languages <nobug>: broken deps on x86_64 and ppc(64)
So, provided that we don't introduce any NEW bugs while fixing THOSE bugs, the tree should be golden as of tonight. We'll begin syncing once we've finished smoke testing the tree tomorrow (you can help too on rawhide!). There will also be a fair number of "0 day" updates for FC6, due to the amount of time that we've been frozen and not taking any updates. Many of these will go into updates-testing first, and some testing on those would be good, since they saw 0 rawhide time.
That is all, I now return you to your regularly scheduled mortgage and lottery spam.