REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Alex Hudson]

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: 
> 
> https://fedoraproject.org/wiki/Stable_release_updates_vision

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
> too. 

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
issues. 

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.

Cheers

Alex.



--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com