How about releasing an update of xorg-x11-drv-intel for Fedora 11

[Michael Schwendt]

On Wed, 14 Oct 2009 13:26:53 -0700, Adam wrote:

> (push some Xorg changes we'd never be happy about putting
> in stable into it). 

If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relying on karma automatism).

However, it could be that you would need to offer a test-update for two or
more months before you would get essential feedback that helps with
deciding whether it's safe to mark it stable or not.

Especially with regard to version upgrades: if you know the current
package release doesn't suffer from any bugs (as tracked via bugzilla)
and a test-update to a new version may cause regression, why rush and
mark it stable without sufficient feedback? Why force users of stable
updates to become guinea pigs?

> I also agree with Kevin - maybe we don't need to
> *disallow* updates sitting in -testing for a long time, but updates
> sitting there for a long time is an indication of potential issues and
> it should be flagged for tracking.

0 karma points is "an indication of potential issues"? Not at all.
0 or +1 karma points after a month doesn't make it safe either to mark it
stable. It depends on _who_ contributed _what_ sorts of tests. It may be
that another important tester finds a show-stopper issue three weeks
later. Sometimes we only win a new tester, who would normally avoid
updates-testing like the plague, for a specific test-update while
communicating within a bugzilla ticket. Sometimes not even that, and
all you can get is to have a reporter download a build from koji.

Now tell me how to attract more testers to try updates-testing and enable
it by default on one machine, perhaps a personal desktop. If we continue
to offer test-updates which may "eat babies", as some of you call it, you
can't win much. Not a big problem for kernel test-updates, which aren't
booted by default, but a threat nevertheless. More of a problem for any of
the other packages which get replaced - and there's a steady flood of
packages in updates-testing. One can hear again and again from users that
they don't like "more bleeding-edge" than "stable updates" and that they
expect the package maintainers to give certain guarantees for the
"stability" of updates they offer. No guarantees => let the community
contribute testing. No testing => keep the test-update in updates-testing.