On Wed, 6 Oct 2010 12:50:00 -0600 Kevin Fenzi wrote:
On Wed, 29 Sep 2010 09:19:08 +0200
Michal Schmidt <mschmidt(a)redhat.com> wrote:
> 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?
The idea is to relax the restrictions on updates to F(n) a bit, while
keeping very strict rules for F(n-1).
Updates to any release must NOT:
- change API, ABI
- change data or configuration formats
- change the GUI in a major way
- change command-line options incompatibly
- remove any features
(Exceptions to these rules will granted only if fixing a security or
data loss bug would be impossible otherwise.)
Given the restrictions above, updates to F(n) are allowed to:
- rebase to new upstream releases
- add new features
- make minor user interface changes
- fix bugs
Updates to F(n-1) are ONLY allowed to:
- fix bugs
- the complete list of which must be included in the update
description; the update must not change anything else.
- cherry-picking of patches may be necessary
Michal