On Tue, 28 Sep 2010 17:14:28 -0600 Kevin Fenzi wrote:
On Tue, 28 Sep 2010 18:45:11 +0200
Jaroslav Reznik <jreznik(a)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.
Michal