Orcan Ogetbil wrote:
> A package destroying people's hardware shouldn't be there in the first
> place, because it should have stayed in testing for an extended period
> of time. Thus this is not a valid reason, as the other ones that were
> brought up were not.
What if nobody with that hardware was using updates-testing? Then it'll only
get noticed once it's stable and starts breaking hardware there. Or even, it
might only come to Fedora's attention due to a warning from upstream, which
may come in at any time.
> But it is maintainer's fault to push an update to stable that would
> *possibly* destroy people's hardware.
He just can't know. Testing is not a magic bullet and testers will not have
every piece of hardware ever produced.
> Standardization, my friend, helps you in many aspects of life.
What you call "standardization", I call "inflexible bureaucracy".
> Indeed some changes are trivial. But if a trivial change is really
> necessary, it could be done while the package is still in testing. If
> you need one liner fix for an already tested package that has been in
> stable for long time, then that fix is apparently not urgent.
It may be a regression which was missed by the people in testing, maybe they
didn't use the affected feature, maybe they don't have the affected
hardware, maybe the intersection of updates-testing users and users of that
particular package is even just empty. Updates-testing is not a silver
bullet.
> Please don't skip the fact that fixes themselves might be broken too,
> even the most trivial ones.
The more trivial the fix, the less likely this is.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
