Jesse Keating wrote:
> various sound issues on intel recently). Upstream isn't perfect, and if
> I had to choose between supporting new people, or keeping existing
> people unbroken, I'll choose on the side of existing people every time.
Actually it might often be the case that adding the support for the new
hardware is the better choice. The "existing people" can just run the old
kernel/driver/whatever until the regression is fixed.
That said, it's a tough topic, because regressions tend to really annoy
people, they feel "WTF, this always worked, WhyTF is it no longer working
now?", even though from a purely practical point of view, unfixed bugs (and
not working on some hardware is practically speaking a bug, even though
technically it's a missing feature) are much worse because there's no
working build to revert to.
One problem is that even once they're known, some of the regressions are
taking a lot of time to fix. If some improvement were possible there,
that'd help a lot, but the complexity of hardware drivers makes things
hard. It's often very difficult to figure out what caused a specific
regression.
What would ideally happen is:
1. The known regressions are fixed (e.g. the rv280 regressions in this
case).
2. The update gets pushed out to updates-testing.
3. If new regressions are found during (1-2 weeks of) testing, go back to
step 1.
4. The update gets pushed out to stable. At this point it is well worth the
remaining risk.
5. Any new bug reports get handled the usual way.
Kernel updates have skipped step 3 in several occasions and got pushed out
to stable despite known regressions. We should try to figure out why it
happened in the different occasions (a tradeoff as described in my first
paragraph? mixing of security fixes with invasive changes in a single
branch? lack of attention to Bodhi feedback? something else?), then we
could propose possible solutions. But I don't think stopping version
upgrades altogether is a solution.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
