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

Kevin Fenzi 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. 

...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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100925/c04c9c67/attachment.bin 


More information about the devel mailing list