On 28/10/2007, David Boles <dgboles@xxxxxxxxx> wrote: > > Well lets see here. > > Say that there are 5 million Fedora users. And some have old laptops. Some > newer laptops. Some brand new laptops. All, or mostly all different makes > models and hardware. Now do the same logic for desktops. Now throw in the > users that have added 'third party' software. Windows codecs. Video > drivers, WiFi drivers. All sorts of 'not standard Fedora' supplied software. It makes no sense to pull 3rd party and "not standard Fedora" supplied software into the mix for this off-topic discussion. Obviously, the development cycle of a Fedora distribution release does not cover any 3rd party software unless those 3rd party developers participate in the development and give feedback. Else it simply isn't feasible. Further, we all know how some types of 3rd party packages can cause Fedora to break badly. It is the responsibility of the 3rd party package providers and their users to reduce the risk of such breakage. Look how some of them prepare development packages in sync with Fedora development (rawhide), i.e. they offer "development" repositories to be used together with Fedora development and test releases. They try to be ready early by participating in the development cycle. With regard to the multitude of different hardware environments, those are very special requirements when specific pieces of hardware are needed to test for and reproduce a failure case -- you only prove my point, albeit with an example where testing is most difficult due to dependencies on hardware (and I said that testing is not easy). Only after installing a kernel update, the user can find out whether the new kernel works. Perhaps mkinitrd creates a bad image on one machine and not on another. Or a damaged grub.conf confuses the kernel update. Yes, plenty of scenarios one could think of. But would you expect every user to track Linus' kernel releases to find regression before the same kernel becomes available as an update via yum? So, especially when you realise that you cannot test enough to make bullet-proof update releases, you try to avoid that risk as much as possible and limit yourself to security errata. For bug-fixes and feature enhancements, you don't have a choice other than to expose an update candidate to the tester community as long as possible, requiring bug reporters to test the updates -- instead of trying to package and publish upstream updates on the same day as upstream (this is especially dangerous when an upstream developer decided to rewrite portions of the code in the middle of a stable release). > Joe Package-builder builds a newer version of something with improvements > or bug fixes. Then tests it on his machine and then puts it in > Updates-testing. Which few, if any, use. So it does not get tested very well. Then keep the update candidate in updates-testing till there is a trade-off between known bugs and hopefully fixed bugs. Why take the risk of declaring it tested and "stable" when you believe it hasn't been tested sufficiently? The distribution's gold release has gone through a long development cycle with several test releases plus at least one freeze. Assume it's working okay unless you get bug reports or find bugs yourself. The "never touch a running system" stance applies fine, and you can focus on development and testing of the next distribution release. I claim that many updates are not tested at all (and are not even test-installed in their target distribution environment). Often they are mass-updates built for several distribution releases only to sync with upstream releases. Not even trying to install the built update candidates in a Fedora N installation is reason #1 why we see broken package dependencies. > You install this package and it breaks some package/function your machine. > > Question? Why is that the exclusive fault of the person who supplied the > package? Nobody has claimed that in general it would be the exclusive fault of the packager.
