On Wed, 22 Sep 2010 18:14:47 +0100 Alex Hudson <fedora@xxxxxxxxxxxxxx> wrote: > Hey Kevin, > > On Tue, 2010-09-21 at 15:47 -0600, Kevin Fenzi wrote: > > How can we clarify the language or the layout of the page to be more > > clear? Are there places that it could be more like the existing > > package update howto page? Could we be more detailed about what > > bodhi enforces and whats just good practice? > > I think there's one thing missing: some discussion about the guiding > principles about where these rules came from. Well, there is the Boards vision that this came out of: https://fedoraproject.org/wiki/Stable_release_updates_vision > > So, for example, we have these use cases for Fedora which involves > information working on the desktop, so the guiding principles for the > stable release ought to be about those users being generally happy and > having a desktop that is working reliably day-by-day. Yes, but I also see the same for the server side... server admins hate having to tweak config files after an update to get a service back up too. > From those types of principles, exceptions like "update clamav" and > "update to Firefox 4 because it's the only secure release" become a > lot more obvious: our users need a working secure desktop, and > updates are about the balancing act between "fixing existing > problems" and "risk of introducing new problems". Right. > While the various rules about karma and updates in series are really > useful, they're more like a set of codified statements about what > risk/reward ratio we think maintainers ought to be considering in > order to fix problems or introduce new features. But if we focus too > hard on them, we risk losing sight of the wood for the trees: I think > they're great for calibrating the risk, but we need to remember what > the goal actually is. Absoletely. Can you think of anything specific to add to the updates policy that would express this? We do have a Philosophy section... can you re-work that to express this? kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
