On Wed, 2010-09-22 at 12:35 -0600, Kevin Fenzi wrote: > Alex Hudson <fedora@xxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
