Proposed udpates policy change

[Dan Horák]

Bill Nottingham píše v Út 09. 03. 2010 v 14:10 -0500: 
> Matthew Garrett (mjg59 at srcf.ucam.org) said: 
> > Introduction
> > ------------
> > 
> > We assume the following axioms:
> > 
> > 1) Updates to stable that result in any reduction of functionality to 
> > the user are unacceptable.
> > 
> > 2) It is impossible to ensure that functionality will not be reduced 
> > without sufficient testing.
> > 
> > 3) Sufficient testing of software inherently requires manual 
> > intervention by more than one individual.
> 
> I agree with the sentiments here.
> 
> > Proposal
> > --------
> > 
> > The ability for maintainers to flag an update directly into the updates 
> > repository will be disabled. Before being added to updates, the package 
> > must receive a net karma of +3 in Bodhi.
> 
> However, I do wonder about some of the concerns about this being
> a requirement for all packages. So, here's a counter-proposal/expansion.
> If need be, each of these policies could be considered separately, although
> they do stack on each other.
> 
> ....
> 
> Proposal
> --------
> 
> For a package to be pushed to the stable updates repository, it must
> meet the following criteria.
> 
> 1) All updates (even security) must pass AutoQA tests.
> 
> Rationale: If a package breaks dependencies, does not install, or
> fails other obvious tests, it should not be pushed. Period. Obviously,
> this proposal would not be enacted until AutoQA is live.
> 
> 2) Updates that constitute a part of the 'important' package set (defined
> below) must follow the rules as defined for critical path packages for
> pending releases, meaning that they require positive karma from releng
> and/or QA before they go stable. This also includes security updates for
> these packages.
> 
> The 'important' package set is defined as the following:
> - The current critical path package set
> - All major desktop environments' core functionality (GNOME, KDE, XFCE,
>   LXDE)
> - Package updating frameworks (gnome-packagekit, kpackagekit)
> - Major desktop productivity apps. An initial list would be firefox,
>   kdebase (konqueror), thunderbird, evolution, kdepim (kmail).
> 
> Rationale: These are the sets of packages where regressions most affect
> users, and would most prevent them from Getting Their Work Done.
> Furthermore, while I can accept that there may be some packages in Fedora that
> cannot find a significant enough testing base for all potential updates, I
> reject the notion that any desktop widely used enough that we deploy a
> image or spin for it would fit into that category. I accept that this places a
> larger burden on QA, and would expect them to be able to contribute testing
> to this initiative.
> 
> 3) All other non-security updates must either: 
> 
>  a) reach their specified bodhi karma threshold
>  b) spend some minimum amount of time in updates-testing, with a tracked
>     number of downloads.
> 
>  Proposed time would be one week, but is open to negotiation.
> 
>  Rationale: We do want additional eyes on updates wherever possible. We do
>    have one Fedora mirror that Fedora infrastructure controls; we should
>    be able to mine this server for data on updates-testing downloads.
> 
> Any update that wants to bypass these procedures would need majority
> approval from FESCo.
> 
> ....
> 
> Comments, questions, reasoned arguments? Part of me wonders if this should be
> expanded with a sliding scale for update types (enhancements, for example, get
> more stringent treatment than bugfix/security).

Thanks Bill, this proposal is very similar to my "dump of ideas" posted
earlier today. The only thing I would like to improve (probably in
PackageKit) is the presentation of the content in updates-testing to the
users, to make it more visible and to encourage the testing. Something
like subscription to selected subset of packages that I want to be
notified about.


Dan