Proposed udpates policy change
Dan Horák
dan at danny.cz
Tue Mar 9 19:49:00 UTC 2010
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
More information about the devel
mailing list