On Tuesday, March 9, 2010, 2:10:04 PM, Bill Nottingham wrote: > 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. This is a sane approach. One problem with immediate implementation would be that all packages, no matter how insignificant would need to have tests that could be run. Some packages in categories such as firmware or cross-compilation tools would require specialized hardware to test fully as part of the build or subsequent AutoQA testing. > 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. Also sane. > 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. Again, sanity. > 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). I think you need to separate enhancements/etc to core components from those for lower risk packages. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
