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

Kevin Fenzi kevin at scrye.com
Wed Oct 6 18:50:00 UTC 2010


On Wed, 29 Sep 2010 09:19:08 +0200
Michal Schmidt <mschmidt at redhat.com> wrote:

> On Tue, 28 Sep 2010 17:14:28 -0600 Kevin Fenzi wrote:
> > On Tue, 28 Sep 2010 18:45:11 +0200
> > Jaroslav Reznik <jreznik at redhat.com> wrote:
> > > 
> > > Ok - that's one problem - we sucks in selective updates and
> > > information for users.
> > >
> > > Other could be - change release scheme:
> > > 1. very similar to current one - rawhide, Fn, Fn-1
> > > * rawhide - really raw development platform
> > > * Fn - live release, similar to current state but more testing
> > > (proventesters, autoqa)
> > > * Fn-1 - do not touch, even more strict rules
> > 
> > Thats what https://fedoraproject.org/wiki/Updates_Policy already
> > attempts to impress on maintainers. 
> 
> In the policy I do not see as clear distinction between F(n) (current
> stable) and F(n-1) (old stable) as Jaroslav proposes. The closest to
> it is this sentence:
>   The update rate for any given release should drop off over time,
>   approaching zero near release end-of-life.
> The wording suggests a continuous rate of change which is weird and
> hard to get right.
> 
> An explicit distinction between F(n) and F(n-1) would make sense for
> at least these reasons:
>  - Many users of F(n) desire current versions of end-user software
>    in updates (of course given that it gets tested sufficiently before
>    being pushed there and that the new version is not a revolutionary
>    change since the previous version).
>  - Some users intentionally install F(n-1) only after F(n) is
> released, believing it to be more stable and more conservative about
> updates (important fixes only) than F(n). I guess this is intuitive
> to users.
>  - F(n)-updates-testing usually has a reasonable amount of users, but
>    much fewer people use F(n-1)-updates-testing.

How would you suggest wording this? The above is what people might
expect from a F(n-1), but what policy would match these goals?

ie, how can we explain how F(n-1) is different from F(n) for
maintainers? What updates should be in one and not the other? 

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/20101006/0da43068/attachment.bin 


More information about the devel mailing list