On Mon, 2012-03-26 at 15:53 -0400, Stephen Gallagher wrote: > So I really see two options for improving these situations: > 1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two > months ago (to silence). The idea would be to add the ability for bodhi > updates to mark other updates as a dependency, so that in the example > above, Firefox could have been marked as ready for stable, but not > pushed until the nss update was also marked as ready for stable. This to > me seems like the best long-term solution. I'd also like to mention that > Ubuntu's Launchpad system has this capability.
> 2) We could continue on the "single update for multiple packages" > approach, but revamp the karma system so that each SRPM gets its own > karma, rather than the update as a whole. Then, the whole update would > not be pushed via autokarma until all of the dependent packages had > sufficient karma (or the owner of the update could push them after the > stable wait period, of course). I think either of these would be an improvement. Both are likely Bodhi 2.0-dependent, though. As I understand the Bodhi 2 design, it would certainly be capable of at least the second (as it's intended to make feedback a much more customizable and granular thing). I think we'd need to make the second more optional than you suggest, though. For instance, when the desktop team pushes a 'GNOME 3.4' update with 30 packages in it, they really want that update to be tested as a whole - broadly they just want people to install all the updates, boot into GNOME, and make sure stuff mostly works. They probably don't want the entire update blocked if there's a typo in the Help file for one of the games, or something. So I think there are cases where an update owner would not want to require the threshold karma on every single sub-package in an update. With that caveat, though, I do like the ideas. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
