It is still under construction and content may change. Do not rely on the information on this page.
It has been suggested by quaid to move or rename this page to "Bodhi_Guide".
Work is underway to merge this guide into the new Bodhi Guide as a permanent location for Bodhi content.
Bodhi workflow and Q&A
What is Bodhi?
From the bodhi web page:
Bodhi is a modular web-system that facilitates the process of publishing updates for a Fedora-based software distribution. It is written in Python and utilizes the TurboGears web framework.
Bodhi is currently being used to push out all package updates for Fedora 7.
How does it work?
- First you must build your package in the koji buildsystem. See the UsingKoji document.
- It is always recommended that you test your package locally to the best of your ability before pushing it into a release.
- Now you can login to the bodhi web interface . You can see a menu on the left:
- Select "New Update" to submit a new update request.
- Select "Pending Updates" to see a list of requests that have been submitted but have yet to be pushed.
- Select "Testing Updates" to see a list of requests that are in the updates-testing repository, but not yet released as stable updates.
- Select "Stable Updates" to see a list of requests that are in the main, stable updates repository.
Submitting a new update
- Log into the Bodhi Website with your Fedora Account.
- Select "New Update" for the appropriate release and type the name of the package that you would like to update. A list should appear with all of the possible builds for this package, if not then you can type the full name-version-release manually. Select the build that is going to be a potential update. You will be able to specify if the package is bugfix, an enhancement, or a security update. You can also specify any bugzilla bugs related to this update and provide any end user notes. (if you submit an update, say from package-1.1 to package-2.0, then the type is "enhancement"). By default, bodhi will close all associated bugs when the update is marked as stable, which can be toggled upon creation.
- bodhi will perform some sanity checks on your update request. Is your package built and available in koji? Is it tagged as an updates candidate for the release you wish to make it available for? The update path for your package will also be checked at this point to make sure you don't release a newer version of a package on an older release. Your update must not break the upgrade path or it will be rejected.
- From here your update is in a 'Pending' state. When you are satisfied with the details of your update, you then must chose to "Push to Testing" or "Push to Stable".
- The signing process is currently done by a human, so you will be notified by email when your update has been signed and pushed, and a package update notification will also be sent to fedora-package-announce or fedora-test-list depending on its status.
- While in the updates-testing repository you may get feedback, both positive and negative. Once enough feedback is generated, you can use the bodhi interface to release your update by clicking 'Mark as Stable', or to remove it click 'Delete'. If your update achieves a karma of 3, it will automatically be pushed to stable, and will be unpushed if it reaches -3.
- After your package is marked as stable, a request will get sent to the Release team and it will be signed and pushed out to the main released updates repository. Note that signing is a manual process and is done as time permits. Upon completion bodhi will optionally close all associated bugs, send out update notices to the appropriate mailing lists, and will notify everyone associated with the update.
States
- NEW - This is when your update request is being submitted.
- PENDING - Your update has not yet been submitted to the Release Team for pushing.
- TESTING - Your package is in the updates-testing repository for people to test.
- STABLE - Your package has been released to the main updates repository.
- OBSOLETE - Your package has been obsoleted by a different update
Note that your update must be unpushed before it can be removed from the system. Only updates in the pending state may be deleted from the updates system. Removal will be done by an admin as time permits.
Questions and Answers
1. Q: What versions of Fedora and EPEL use or will use Bodhi? A: Fedora 7 utilizes Bodhi, as will Fedora 8. All EPEL releases will use bodhi as soon as they are ported over to the Koji Buildsystem.
2. Q: Won't this slow down development / rawhide packages? A: bodhi will NOT be used for development / rawhide. Package builds there will (usually) be available in the next rawhide push. The exception being periods where there is a freeze in effect.
3. Q: Why do we need bodhi? What was wrong with just always pushing updates right out? A: There are lots of advantages to an updates system like bodhi, to name a few:
- New packages entering the collection can be announced to users.
- The reasons for an update can be communicated to end users.
- Bodhi generates extended update metadata which is parsed client-side by yum.
- Security updates can be seen by users as a separate channel, with links to the security advisories.
- Automated testing can be done on updates before they are released.
- End users and QA folks who wish to can test updates before they are released.
4. Q: Is there a command line interface to bodhi? Do I have to have web access? A: The bodhi-client package will be available in Fedora shortly.
5. Q: I want to push my package directly out, bypassing testing. A: Then once you submit your update, press "Push to Stable". Simple as that.
6. Q: What do I put in the "Notes" section of an update? A: It's up to you as maintainer. Consider that end users would like to know why they just downloaded this update. Does it add anything? Fix a bug? If it's a new package, consider adding in a copy of the description so end users will know what it is.
7. Q: Are we going to have any rule for how long things should be in updates-testing? How much QA? How many good/bad? A: Right now bodhi will automatically stabalize updates once they reach a karma of 3. Releng and security team members have full control of the updates, as well as the person that submits them.