[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Yum problem

On 28/10/2007, David Boles <dgboles gmail com> 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]