Matthew Garrett (mjg59@xxxxxxxxxxxxx) 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).
Bill
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
