On Wed, 6 Oct 2010 12:50:00 -0600 Kevin Fenzi wrote:
> On Wed, 29 Sep 2010 09:19:08 +0200
> Michal Schmidt <mschmidt@xxxxxxxxxx> 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
