Michael Schwendt wrote:
That would be a ridiculous decision. It would be much better to
disable
that feature only for those update submitters who really have been
dilettantish enough to use it inappropriately more than once.
Yeah, that's a good idea. We really need to avoid punishing everyone for the
few incompetent maintainers who screw up!
> * A new package which doesn't replace anything, and which I
verified to
> work fine for me. It's clearly not a completely broken package and
> there's no way it can break anybody's existing setup as nobody has that
> package yet.
Unconvincing, though. History has shown that some packagers still managed
to push new packages that suffered from broken deps and failure to start
at run-time (and even misplaced files). Especially for _new_ packages,
dep-breakage would be avoidable by pushing them as test-updates as long as
there is not integrated depchecking yet.
Well, as I wrote, the packager should have tested the package he's pushing
out, of course! Especially for a new package, it's the only way to know it
works. Something that doesn't work at all has no business being pushed to
anywhere, even testing. And yes, checking that the dependencies are all in
Fedora is definitely a good idea, too. (But automated depchecks would solve
that problem once and for all.)
> * A regression which causes big breakage at least for some people
slipped
> through testing for whatever reason. We urgently want the fix to get out
> ASAP.
>
> * A regression slipped through testing for whatever reason and the patch
> is trivial. We want the fix to get out ASAP, and the risk of breakage is
> very low.
The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
> * A trivial bugfix (like a one-line diff), tested and confirmed
to fix
> the bug by at least one person. The risk of breakage is extremely low.
For some bugs and some bug-fixes [and some packages], waiting for testers
is just a waste of time.
Indeed.
Kevin Kofler