This post is part of a series intended to provide those new to Bodhi with an introduction to some Bodhi basics. This post hopes to both introduce the life cycle of an update in Bodhi, as well as to outline the proposed addition of a ‘batched’ request intended to reduce update churn. If you’re a seasoned Bodhi user, you can jump to the Proposed revisions to an update’s life cycle section.
An update’s life cycle
First, a user creates a new update or edits an existing update. Updates have plenty of different attributes, but for the purpose of this brief introduction, I will only mention that the updates have a type, severity, status, and request.
The update’s type (i.e., bugfix, security, newpackage, enhancement) classifies the update in relative terms of how it will help the end-user. The update’s severity (i.e., unspecified, urgent, high, medium, low) ranks the importance of getting the update to the end-user. Throughout their life cycle, updates flow through a series of requests and statuses. An update’s status is the current state of the update (i.e., pending, testing, stable, unpushed, obsolete, or processing). An update can request to enter a status (i.e., testing, obsolete, unpush, revoke, stable). If the update meets the requirements for the requested status, it enters that status upon the next mash run.
The update begins in the pending state and remains in pending until it requests to be pushed to the testing or stable repository. Once the update is testing, the update will be tested by other users and receive feedback in the form of comments and karma (i.e., -1, 0, +1). The update is eligible to be pushed to the stable repository when it meets the testing requirements (i.e., the update either meets the mandatory number of days in the testing state or reaches the minimum number of positive karma). Note: Additionally, the update can request to be “unpushed”, “revoked”, or “obsolete” from any state, but we will not cover these states here.
Currently, after the update meets the testing requirements, the next logical step is requesting to enter the stable repository. With autokarma enabled, the update automatically reaches the stable repository upon meeting the testing requirements. With autokarma disabled, the user will be presented with a UI option to push the update to stable upon meeting the testing requirements.
The current update life cycle
Proposed revisions to an update’s life cycle
In response to requests to reduce update churn, we will add an additional path to the update’s life cycle. This path will essentially gather a batch of updates (namely, all of the updates that have been approved to be pushed to stable) and put this batch in a queue. This batch will request to be pushed to stable once a week. This should result in a smoother experience for end-users, as they will only receive a new batch of updates once a week, as opposed to once a day. This should slightly reduce the mash time six days of the week.
The new update life cycle
Instead of immediately requesting to be pushed to stable after meeting the update requirements, the update will instead request to be batched. If autokarma is enabled, the update will immediately be moved to a batched request upon meeting the update requirements. If autokarma is disabled, the user will be presented with a UI option to move the update to a batched request upon meeting the update requirements.
Once the update is sitting as a batched request, it will proceed as before (with the exception of waiting in a queue for up to seven days). If the packager should believe the update would benefit from an immediate request to stable, (s)he will now have the option to immediately request stable (and thus bypassing the batched request) via a UI option. Otherwise, once a week, a cron job will execute a script setting the request of all updates currently requesting batched to request stable.
If the update’s severity is urgent or if the update’s type is newpackage, the update will bypass the batched request and immediately request to be pushed to stable. Urgent updates need to reach end users as soon as possible, so holding them in a queue wouldn’t be beneficial. Additionally, newpackage updates already tend to have a long process time, and we do not want to further slow their process time.
The current PR can be found here. Feel free to leave any feedback on the PR or as a response to the email with the subject “Two more concrete ideas for what a once-yearly+update schedule would look like” on the Fedora dev mailing list.