On Sat, 2010-08-14 at 11:07 +0200, Kevin Kofler wrote: > David Malcolm wrote: > > I think that a distinction can be made between core packages that many > > different components depend upon versus "leaf" packages that do their > > own thing and no other component relies on. I do think we should be > > conservative when updating core components in released versions of > > Fedora; with rawhide much less so. But perhaps "leaf" packages can have > > a less conservative policy. > > Well, a backwards-compatible update to a core library isn't normally a > problem. Of course it doesn't make sense to push a soname bump of something > like Boost to a stable release. An update of something guaranteeing > backwards binary compatibility, e.g. Qt or KDE, on the other hand, is quite > safe to push, after adequate testing. And "leaf" also needs to be qualified, > a library that's used by only a small number of applications can be updated > to a binary-incompatible version in a grouped update with the affected > applications: for example, this has often been done to add new hardware > support to libmtp and a few other such libraries, and those updates have > been very nice for the people with the affected hardware and didn't cause > any trouble for anyone else. > IMHO, labriaries should be updated in stable release only if there's no backwards-incompatible change or if there's a really strong reason to update that outweights the problems caused by API/ABI change. We could probably be much more lenient with end-user apss, but proper testing is always a must (and yes, more testers would be *very* helpful). Seeing your mail, you more or less agree with this. So why exactly are you against the policy explicitly requiring either positive karma or some minimal time in testing (setting aside some current shrotcommings of the implementation like resetting the timer on bug update when you just add/remove fixed bug or edit update comment)? Martin
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
