Hi, 2010/3/9 Rahul Sundaram <metherid@xxxxxxxxx>: > Hi, > > Since it is the fav season for proposals apparently, let me throw in my > Fedora/hat in the ring too. This only applies to updates to general > releases. > > For critical path packages > (http://fedoraproject.org/wiki/Critical_Path_Packages) : > > * Must go through updates-testing repository > * Only major bug fixes and security fixes. > * Must go through updates testing repository even for security fixes Let's consider a case - there is a giant hole in kernel - and there is a remote exploit somewhere in the wild. Do we want to wait a few days or so when package will go through updates-testing? There should be an exception to this rule for fixes for a _real_ security threads. > Rationale: Expedited security fixes have caused some serious regressions > in the past (D-Bus, Bind, Thunderbird updates etc). > * Requires QA team to sign off on these updates and I will leave them > to define the criteria for it. I believe the criteria should be based > on feedback from testers rather than the number of days. > * Exceptions or expedited update requests must go via release engineering > > Non-critical path packages > > * Don't blindly push every upstream release as update > * Preserve stability and avoid unexpected changes and push updates with > enhancements only if the benefit is considered worth the risk of > potential regressions > > Recommendations: > > * Run AutoQA on all updates > * Hookup PackageKit to updates-testing repo and allow users to opt-in > and provide feedback easily > * Evaluate extending the criteria based on how well we succeed with a > more conservative update policy for critical path packages > > Let me know what you think +1 > > Rahul > Regards, Michal -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
