Bill Nottingham píše v Út 09. 03. 2010 v 14:10 -0500: > 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). 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
