fedora at alexhudson.com
Wed Sep 22 19:14:45 UTC 2010
On Wed, 2010-09-22 at 12:35 -0600, Kevin Fenzi wrote:
> Alex Hudson <fedora at alexhudson.com> wrote:
> > 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:
Yeah; and I think that's great - I think possibly the Updates Policy
could use some kind of practical view of that or reference to it. A
simple sentence in the intro along the lines of "This update policy is
an attempt to achieve this vision" might be enough - it's almost the
yardstick by which the update policy should be measured.
> > 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
I think that's true, to some extent. I think there is a real issue with
the server-side stuff, though, because I think server admins are a lot
less tolerant of update breakage and a lot more sensitive to security
On this list, the question of whether Fedora is suitable as a server OS
is frequently mooted.
My take would be that it's an absolute shame to write off Fedora for
that use-case, but that this update policy probably isn't enough to
address it: e.g. should PHP be updated relatively quickly so desktop web
developers can have at it and test, or should there be an attitude that
regressions are to be avoided? I think server admins would be a lot more
conservative than web coders. There's a lot of tension in those use
cases; I would say to put it to one side for now.
> > 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?
I'll try to have a think about this and propose something.
I think also there is a flip-side to this which hasn't been considered
so expressly: the update policy is almost a brake on updates, but what
happens when a bad update goes through? I think there ought to be
something in the policy which says "If a bad update gets through, you
either revert it or fix it. The more 'stable' the update should have
been, the stronger the urge should be to revert it.". (By revert, I mean
go to the previous package, but probably with a bumped version - not
some mechanism to pull bad updates).
And if we're saying that there ought to be that "revert" escape route,
then in the same way we have a Plan B on features pages, that ought to
be another factor maintainers consider: "If this goes wrong and you need
to revert this, is that possible?". If the answer to that question is
"No", i.e. the new version app does some one-direction-only data
conversion when it's run for the first time, then that ought to be
another factor weighing against that update going through.
This message was scanned by Better Hosted and is believed to be clean.
More information about the devel