kevin at scrye.com
Wed Sep 22 18:35:32 UTC 2010
On Wed, 22 Sep 2010 18:14:47 +0100
Alex Hudson <fedora at alexhudson.com> 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:
> 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
> 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".
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100922/814c2d92/attachment.bin
More information about the devel