On Wed, 22 Sep 2010 20:14:45 +0100
Alex Hudson <fedora(a)alexhudson.com> wrote:
On Wed, 2010-09-22 at 12:35 -0600, Kevin Fenzi wrote:
> Alex Hudson <fedora(a)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.
I've added some more to the introduction and pointed to that.
Thanks for the suggestion.
...snip...
> 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).
Good idea. I think this might require consensus from fesco, but adding
something like that sounds good to me.
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.
Good suggestion.
kevin