= Proposal topic =
Modify the update acceptance criteria for pre-release updates
= Overview =
Ever since we've established our new branching setup, updates that are produced between the branch point and GA are subject to the same procedure as post-release updates, including the acceptance criteria for stable updates.
= Problem space =
The acceptance criteria are designed with a focus on slowing down updates and preventing regressions. Applying these criteria to the heavy bug-fixing phase between alpha and beta leads to huge numbers of testing updates that wait for sufficient karma, and causes unfortunate long turnaround times for bug fixes.
= Solution Overview =
I've talked to Luke, and he said that it should not be a problem to make bodhi apply a different set of update criteria for pre-release updates, and he can have the necessary changes in place for the F15 cycle.
= Active Ingredients =
Update bodhi to enable different acceptance criteria for different parts of the release lifecycle.
Update the package acceptance criteria for pre-release packages. Here is my proposal:
== Pre-release updates ==
Package builds that are created after a release has branched off from rawhide are subject to the same update mechanisms as post-release builds (i.e. an update has to be created in bodhi, and has to be pushed to an updates-testing repository before it can enter the branched stream).
In order to facilitate bug-fixing, and reduce turnaround times, updates that are created before the beta release have lighter acceptance criteria. Pre-beta 'critical path' updates must receive positive karma from a Proventester, before they can be pushed to stable. All other pre-beta updates can be pushed to stable after spending at least 3 days in updates-testing.
Updates between beta and and the final release are subject to the same acceptance criteria as post-release updates. In addition, updates that are filed during the 'release candidate' phase are only acceptable if they fix blocker bugs.
= Owners =
Matthias Clasen
We will revisit this next week.
The other issues I've experienced with the long update gestation period is: 1) if you have a newer version of the package it all starts again. In this case you may actually wait for the 7 days so you can get some important fixes out before having to start the process again. 2) The nightly compose seems to be the process that sets the flag that allows you to progress from testing to updates. Once this is set you then have to wait an 8th day to actually get the update into stable. Like the "auto push to stable when there's enough karma" checkbox there should be the same option for time so that for non crit path packages you don't end up having to login and push the package and end up having to wait another day.
As I wont be able to make it for the meeting today, I'd like to vote here:
+1 to the initial proposal as long as after beta freeze the post-release rules apply.
+1 to a change in bodhi that ether adds a second checkbox "auto push update after the minimum amount of time has passed" or make the existing checkbox "auto push the update when the package update acceptance criteria are met". I prefer the separate checkbox and that it is not checked by default because positive karma says more than a certain time span in updates-testing. -1 to letting updates in rc phase pass "if they fix bugs", especially since this term also includes crit path packages. Each update should still be signed of by rel-eng.
Sorry, the last point should not get lost due to improper formatting, so here it is again:
-1 to letting updates in rc phase pass "if they fix bugs", especially since this term also includes crit path packages. Each update should still be signed of by rel-eng.
This was approved at the 2010-09-07 meeting. Need documentation before f15 branch point. This will not affect f14.
I have now filed bodhi ticket https://fedorahosted.org/bodhi/ticket/482 to track the implementation.
This has already been approved and will happen next cycle. Closing now.
Login to comment on this ticket.