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

[Michal Schmidt]

On Wed, 6 Oct 2010 12:50:00 -0600 Kevin Fenzi wrote:
> On Wed, 29 Sep 2010 09:19:08 +0200
> Michal Schmidt <mschmidt at 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