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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
