kevin at scrye.com
Sat Sep 25 19:03:18 UTC 2010
On Wed, 22 Sep 2010 20:14:45 +0100
Alex Hudson <fedora at alexhudson.com> wrote:
> 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.
I've added some more to the introduction and pointed to that.
Thanks for the suggestion.
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100925/c04c9c67/attachment.bin
More information about the devel