From Fedora Project Wiki

m (→‎What is Bodhi: copy-edit)
(55 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
= Scope of this document =
= Scope of this document =


This document gives an introduction on what Bodhi is and its uses in real-time. This is a work in progress and hence the document currently targets end-users, however this document would be updated periodically to target everyone.
This document provides an introduction explaining what is Bodhi and its uses in real-time. This document is a work in progress and hence it currently targets end-users, however, this document may be updated periodically to target everyone.


= Targeted Audience =
= Targeted Audience =


This document is targeted towards end users and people part of the engineering team.
This document is targeted towards both end users and Fedora developers


= What is Bodhi =
= What is Bodhi =


[https://fedorahosted.org/bodhi/ Bodhi] pronounced as bo-dee is a buddhist term for the wisdom by which one attains enlightenment. Bodhi is a modular web-based system that facilitates the process of publishing package updates for fedora-based software distribution. Bodhi is currently used to send out package updates for Fedora. Bodhi is a system internal to Red Hat.It maintains a single stage of repositories by adding/updating/removing packages.
[https://bodhi.fedoraproject.org Bodhi] pronounced as bo-dee is a Buddhist term for the wisdom by which one attains enlightenment. Bodhi is a modular web-based system that facilitates the process of publishing package updates for Fedora. Bodhi is the application that manages updates for Fedora releases. It maintains a single stage of repositories by adding/updating/removing packages. It can be used to create or modify updates and overrides.


== Advantages of Bodhi ==
== Advantages of Bodhi ==
Line 15: Line 16:
* Provides an intuitive interface for developers and release engineers to manage pushing out package updates for multiple version releases.
* Provides an intuitive interface for developers and release engineers to manage pushing out package updates for multiple version releases.
* Helps in delivering quality packages and repository sustainment with automated testing.
* Helps in delivering quality packages and repository sustainment with automated testing.
* Helps Community testers to get involved in testing of the package updates and provide quality feedback which would reach the packagers/developers.
* Helps Community testers to get involved in the testing of the package updates and provide quality feedback which would reach the packagers/developers.
* Provides a modular framework that will allow future integrations to various other QA and developer tools.
* Provides a modular framework that will allow future integrations to various other QA and developer tools.
 
* Announces the arrival of New packages entering the collection.
* New packages entering the collection can be announced to users.
* The reasons for an update can be communicated to end users.
* The reasons for an update can be communicated to end users.
* Bodhi generates extended update metadata which is parsed client-side by yum.
* 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.
* Allows security updates to 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.
* Accommodates automated testing for updates before the latter are released.
* End users and QA folks who wish to can test updates before they are released.
* Provides pre-release test updates for end users and QA folks who wish to test these updates.


= Workflow =
= Workflow =


First you must build your package in the [http://koji.fedoraproject.org Koji] buildsystem. See the relative [[Using the Koji build system|guide]].
First you must build your package in the [http://koji.fedoraproject.org Koji] buildsystem. See the related [[Using the Koji build system|guide]].


It is always recommended that you test your package locally to the best of your ability before pushing it into a release.
It is always recommended that you test your package locally to the best of your ability before pushing it into a release.


Packages must then move through the following states in Bodhi.
You can submit updates to Bodhi in the following ways:
 
* [[#Using_the_bodhi_command-line_client|Use the Bodhi command line interface]]
 
* or, you can run the following from the git branch of your package:
 
<pre>$ fedpkg update</pre>
 
* The [https://admin.fedoraproject.org/updates bodhi web interface]
 
You can see a menu on the left:
 
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.  By default, bodhi will close all associated bugs when the update is marked as stable, which can be toggled upon creation.


== Package States ==
== Package States ==
Line 39: Line 51:
* '''PENDING''' - Your update has not yet been pushed to the testing or stable repositories.
* '''PENDING''' - Your update has not yet been pushed to the testing or stable repositories.
* '''TESTING''' - Your package is in the updates-testing repository for people to test.
* '''TESTING''' - Your package is in the updates-testing repository for people to test.
* '''TESTING/BATCHED''' - Your package is ready to go stable, and will wait until the next Tuesday's update batch to be marked for stable.
* '''TESTING/STABLE''' - Your package is ready to go stable, and will wait until the next daily update push.
* '''STABLE''' - Your package has been released to the main updates repository.
* '''STABLE''' - Your package has been released to the main updates repository.
* '''OBSOLETE''' - Your package has been obsoleted by a different update
* '''OBSOLETE''' - Your package has been obsoleted by a different update
Line 44: Line 58:
=== Pending ===
=== Pending ===


Once your update is submitted to bodhi, it will enter the ''Pending'' state.  You can submit updates to Bodhi in the following ways:
Once your update is submitted to bodhi, it will enter the ''Pending'' state.   
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.


* The [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client] command line interface
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.


<code>$ bodhi --new --release F7 --type bugfix bodhi-0.4.2-1.fc7</code>
=== Testing ===


* or, you can run the following from the CVS branch of your package:
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 remove it using 'Delete'. 


<code>$ make update</code>
If you chose to use the 'karma automatism' feature when submitting your update, it will automatically be pushed or unpushed based on the feedback from testers.
* The [https://admin.fedoraproject.org/updates bodhi web interface]
This feature can be disabled if you wish to push your update to the stable repository manually.  By default,
 
if your update achieves a karma of 3, it will automatically be pushed to stable and will be unpushed if it reaches -3.
You can see a menu on the left:
 
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.  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.
Testing also has two possible substates, both expressed as the "request", that occur when your package is ready to go to stable. These are documented in the next two sections.


When you are satisfied with the details of your update, you then choose "Push to Testing". Alternatively "Push to Stable" may be selected to skip the testing state.
=== Testing/Batched ===


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.
The "batched" state means that the package is ready to go to stable and is waiting until the next Tuesday when Bodhi will automatically switch the request to "stable" at 03:00 UTC. All non-urgent and non-newpackage updates will automatically move to this state when they hit the karma threshold if they have autokarma enabled, and non-autokarma updates that meet the requirements will present a "Push to Batched" button to the maintainers. The update remains in the testing repository while it is in this state.


=== Testing ===
=== Testing/Stable ===


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'.
The second request state is "stable", and means that the package will be sent out to the stable repositories the next time a [[ReleaseEngineering|Release Engineer]] runs the daily updates push command. The update will remain in the testing repository during this state.


If you chose to use the 'karma automatism' feature when submitting your update, it will automatically be pushed or unpushed based on the feedback from testers.
Developers are encouraged to use the batched update state for updates that are not severe as it reduces the update churn for Fedora's end users and also improves the speed of most of Bodhi's daily pushes (except for the larger Tuesday pushes, of course). However, it remains the maintainer's option to choose when they use the "Push to Stable" button, which will remain available to them.
This feature can be disabled if you wish to push your update to the stable repository manually.  By default, for non-critical path updates,  
if your update achieves a karma of 3, it will automatically be pushed to stable, and will be unpushed if it reaches -3.
   
   
=== Stable ===
=== Stable ===


After your package is marked as stable, a request will get sent to the [[ReleaseEngineering|RelEng 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.
After your package is marked as stable, a request will get sent to the [[ReleaseEngineering|RelEng team]] and it will be signed and pushed out to the main released updates repository. 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.


=== Obsolete ===
=== Obsolete ===
Line 83: Line 93:
= Karma =
= Karma =


Bodhi Karma is a simple +1/-1 voting system that allows for testers
Bodhi Karma is a simple +1/-1 voting system that allows for testers to provide feedback as to whether a given update works or not. The karma of a given update is the sum of the karma of all of its comments. A guide for providing feedback on updates is available at [[QA:Update_feedback_guidelines]].
to provide feedback as to whether a given update works or not.
The karma of a given update is the sum of the karma of all of it's comments.


== Karma requirements for Critical Path updates ==
== Karma requirements for Critical Path updates ==


Bodhi has begun implementing the new [[Package update acceptance criteria]], and currently applies karma-based policy to updates for [[Critical Path Packages]] for Fedora releases.
Critical Path updates require a karma sum of +2 or can be pushed after a 14-day wait if they have received no negative karma. See the [[Updates_Policy]] for details: the Updates Policy page is always the canonical source for update karma requirements.
   
    Critical path package updates for Fedora releases require a karma sum of +2  
    from authenticated users, including positive karma from 1 [[Proventester]].


== Possible workflows with the karma system ==
== Possible workflows with the karma system ==
Line 99: Line 104:
When submitting an update, you can tell bodhi to automatically push it to stable once it has reached a given karma threshold.  This threshold defaults to +3 for marking an update as "stable", and -3 for marking it as "unstable".  These defaults are obviously not suitable for all updates, so the maintainer may configure these values as they wish.
When submitting an update, you can tell bodhi to automatically push it to stable once it has reached a given karma threshold.  This threshold defaults to +3 for marking an update as "stable", and -3 for marking it as "unstable".  These defaults are obviously not suitable for all updates, so the maintainer may configure these values as they wish.


For [https://fedoraproject.org/wiki/Critical_Path_Packages Critical Path Updates], you can still set a threshold, but it must first meet the [https://fedoraproject.org/wiki/Bodhi#Karma_requirements_for_Critical_Path_updates karma requirements for critical path updates].
For [[Critical path package|Critical Path Updates]], you can still set a threshold, but it must first meet the [[Bodhi#Karma_requirements_for_Critical_Path_updates|karma requirements for critical path updates]].


=== Manual intervention ===
=== Manual intervention ===
Maintainers can disable the automatic pushing and manually submit their update to the stable repository once they deem it appropriate.
Maintainers can disable the automatic pushing and manually submit their update to the stable repository once they deem it appropriate. Updates to non-Critical Path packages must either have a karma sum of at least +1 or have been in updates-testing for 7 days with no negative feedback before they can be pushed manually. See the canonical [[Updates_Policy]] for further details.
How to help test critical updates in Fedora


= How to help test important updates using Bodhi =
= How to help test important updates using Bodhi =


For details on the Proven Tester procedures and mentoring process, see the wiki page [https://fedoraproject.org/wiki/Proven_tester here]
For instructions on when to leave positive, negative, neutral or no feedback on an update, see [[QA:Update_feedback_guidelines|here]].


== Using the bodhi web interface ==
== Using the bodhi web interface ==


https://admin.fedoraproject.org/updates/critpath?release=F13
https://bodhi.fedoraproject.org
 
You can optionally pass in a specific 'release'.


You can optionally pass in a specific 'release' or an 'untested' flag,
https://bodhi.fedoraproject.org/releases/F{{FedoraVersionNumber|current}}
which will return a list of critical path updates that have yet to be
approved.


== Using the bodhi command-line client ==
== Using the bodhi command-line client ==
=== Bodhi version 2 ===
Bodhi 2 is included in Fedora >= 26. If you are on a Fedora release older than Fedora 26, you can install bodhi 2 from Copr.
See [[Bodhi/bodhi-client]] on how to use the command line interface.
=== Bodhi version 1 ===
See [https://fedorahosted.org/bodhi/wiki/CLI bodhi-client] on how to use the command line interface.


<code>bodhi --testable --critpath --type=security</code>
<code>bodhi --testable --critpath --type=security</code>


<code>bodhi --testable --type=security</code>
<code>bodhi --testable --type=security</code>
Submit a update:
<code>$ bodhi --new --release F7 --type bugfix bodhi-0.4.2-1.fc7</code>


== Using the Fedora Community dashboard ==
== Using the Fedora Community dashboard ==
Line 128: Line 146:


== Using the fedora-easy-karma tool ==
== Using the fedora-easy-karma tool ==
https://fedoraproject.org/wiki/Fedora_Easy_Karma
[[Fedora Easy Karma]]


= Questions and Answers =
= Questions and Answers =
Line 135: Line 153:
A: Fedora utilizes Bodhi as of Fedora 7.  EPEL now utilizes Koji and Bodhi.
A: Fedora utilizes Bodhi as of Fedora 7.  EPEL now utilizes Koji and Bodhi.


2. Q: Won't this slow down development / rawhide packages?
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.
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?
3. Q: Why do we need bodhi? What was wrong with just always pushing updates right out?
Line 152: Line 170:


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?
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.
A: Right now bodhi will automatically stabilize 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.
 
8: Q: How fetch really new Fedora packages with Bodhi ? 
A: `bodhi updates download --updateid FEDORA-2018-42024244f2` or `bodhi updates query --packages rust --releases f28 --status pending; bodhi updates download --builds rust-1.28.0-2.fc28` more details on https://utcc.utoronto.ca/~cks/space/blog/linux/FedoraBodhiGetPackages


== Outstanding Questions ==
== Outstanding Questions ==
Line 169: Line 190:
To give a concrete example: nss was split into three stand-alone packages,
To give a concrete example: nss was split into three stand-alone packages,
nss, nss-softokn, and nss-util. nss depends on nss-softokn and both nss and  
nss, nss-softokn, and nss-util. nss depends on nss-softokn and both nss and  
nss-soktokn depend on nss-util. They all in turn depend on nspr. nss-softokn
nss-soktokn depend on nss-util. They all, in turn, depend on nspr. nss-softokn
is updated independently of, and less frequently than, nss whereas the nss-util
is updated independently of, and less frequently than, nss whereas the nss-util
package is usually updated in synchrony with nss. If several of these are
package is usually updated in synchrony with nss. If several of these are
Line 178: Line 199:
that the package and its dependencies are submitted as one unit.  
that the package and its dependencies are submitted as one unit.  


Via the command line interface: it is not clear from the documentation how
Via the command line interface: you can do it also by adding all needed builds
to accomplish an update as a unit or that one can do it at all.


If the package has a dependency on another package maintained by someone else one
If the package has a dependency on another package maintained by someone else one still make a bundle, e.g., Firefox, xulrunner, and the nss packages are sometimes released together as a "bundle" in Bodhi.
still make a bundle.


== Ideas for improving the Karma System ==
== Ideas for improving the Karma System ==
* http://bochecha.fedorapeople.org/bodhi_karma_revamped
* http://bochecha.fedorapeople.org/bodhi_karma_revamped
* http://lists.fedoraproject.org/pipermail/devel/2010-March/134087.html
* http://lists.fedoraproject.org/pipermail/devel/2010-March/134087.html

Revision as of 00:57, 4 March 2020

Scope of this document

This document provides an introduction explaining what is Bodhi and its uses in real-time. This document is a work in progress and hence it currently targets end-users, however, this document may be updated periodically to target everyone.

Targeted Audience

This document is targeted towards both end users and Fedora developers

What is Bodhi

Bodhi pronounced as bo-dee is a Buddhist term for the wisdom by which one attains enlightenment. Bodhi is a modular web-based system that facilitates the process of publishing package updates for Fedora. Bodhi is the application that manages updates for Fedora releases. It maintains a single stage of repositories by adding/updating/removing packages. It can be used to create or modify updates and overrides.

Advantages of Bodhi

  • Provides an intuitive interface for developers and release engineers to manage pushing out package updates for multiple version releases.
  • Helps in delivering quality packages and repository sustainment with automated testing.
  • Helps Community testers to get involved in the testing of the package updates and provide quality feedback which would reach the packagers/developers.
  • Provides a modular framework that will allow future integrations to various other QA and developer tools.
  • Announces the arrival of New packages entering the collection.
  • The reasons for an update can be communicated to end users.
  • Generates extended update metadata which is parsed client-side by yum.
  • Allows security updates to be seen by users as a separate channel, with links to the security advisories.
  • Accommodates automated testing for updates before the latter are released.
  • Provides pre-release test updates for end users and QA folks who wish to test these updates.

Workflow

First you must build your package in the Koji buildsystem. See the related guide.

It is always recommended that you test your package locally to the best of your ability before pushing it into a release.

You can submit updates to Bodhi in the following ways:

  • or, you can run the following from the git branch of your package:
$ fedpkg update

You can see a menu on the left:

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. By default, bodhi will close all associated bugs when the update is marked as stable, which can be toggled upon creation.

Package States

Once submitted to Bodhi, packages move through the following states:

  • PENDING - Your update has not yet been pushed to the testing or stable repositories.
  • TESTING - Your package is in the updates-testing repository for people to test.
  • TESTING/BATCHED - Your package is ready to go stable, and will wait until the next Tuesday's update batch to be marked for stable.
  • TESTING/STABLE - Your package is ready to go stable, and will wait until the next daily update push.
  • STABLE - Your package has been released to the main updates repository.
  • OBSOLETE - Your package has been obsoleted by a different update

Pending

Once your update is submitted to bodhi, it will enter the Pending state. 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.

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.

Testing

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 remove it using 'Delete'.

If you chose to use the 'karma automatism' feature when submitting your update, it will automatically be pushed or unpushed based on the feedback from testers. This feature can be disabled if you wish to push your update to the stable repository manually. By default, if your update achieves a karma of 3, it will automatically be pushed to stable and will be unpushed if it reaches -3.

Testing also has two possible substates, both expressed as the "request", that occur when your package is ready to go to stable. These are documented in the next two sections.

Testing/Batched

The "batched" state means that the package is ready to go to stable and is waiting until the next Tuesday when Bodhi will automatically switch the request to "stable" at 03:00 UTC. All non-urgent and non-newpackage updates will automatically move to this state when they hit the karma threshold if they have autokarma enabled, and non-autokarma updates that meet the requirements will present a "Push to Batched" button to the maintainers. The update remains in the testing repository while it is in this state.

Testing/Stable

The second request state is "stable", and means that the package will be sent out to the stable repositories the next time a Release Engineer runs the daily updates push command. The update will remain in the testing repository during this state.

Developers are encouraged to use the batched update state for updates that are not severe as it reduces the update churn for Fedora's end users and also improves the speed of most of Bodhi's daily pushes (except for the larger Tuesday pushes, of course). However, it remains the maintainer's option to choose when they use the "Push to Stable" button, which will remain available to them.

Stable

After your package is marked as stable, a request will get sent to the RelEng team and it will be signed and pushed out to the main released updates repository. 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.

Obsolete

When submitting a new version of a package, bodhi will automatically obsolete any pending or testing updates that do not have an active push request. Once obsoleted, your new update will inherit the old updates Bugs and Notes.

Karma

Bodhi Karma is a simple +1/-1 voting system that allows for testers to provide feedback as to whether a given update works or not. The karma of a given update is the sum of the karma of all of its comments. A guide for providing feedback on updates is available at QA:Update_feedback_guidelines.

Karma requirements for Critical Path updates

Critical Path updates require a karma sum of +2 or can be pushed after a 14-day wait if they have received no negative karma. See the Updates_Policy for details: the Updates Policy page is always the canonical source for update karma requirements.

Possible workflows with the karma system

Karma Automatism

When submitting an update, you can tell bodhi to automatically push it to stable once it has reached a given karma threshold. This threshold defaults to +3 for marking an update as "stable", and -3 for marking it as "unstable". These defaults are obviously not suitable for all updates, so the maintainer may configure these values as they wish.

For Critical Path Updates, you can still set a threshold, but it must first meet the karma requirements for critical path updates.

Manual intervention

Maintainers can disable the automatic pushing and manually submit their update to the stable repository once they deem it appropriate. Updates to non-Critical Path packages must either have a karma sum of at least +1 or have been in updates-testing for 7 days with no negative feedback before they can be pushed manually. See the canonical Updates_Policy for further details.

How to help test important updates using Bodhi

For instructions on when to leave positive, negative, neutral or no feedback on an update, see here.

Using the bodhi web interface

https://bodhi.fedoraproject.org

You can optionally pass in a specific 'release'.

https://bodhi.fedoraproject.org/releases/F39

Using the bodhi command-line client

Bodhi version 2

Bodhi 2 is included in Fedora >= 26. If you are on a Fedora release older than Fedora 26, you can install bodhi 2 from Copr.

See Bodhi/bodhi-client on how to use the command line interface.

Bodhi version 1

See bodhi-client on how to use the command line interface.

bodhi --testable --critpath --type=security

bodhi --testable --type=security

Submit a update:

$ bodhi --new --release F7 --type bugfix bodhi-0.4.2-1.fc7

Using the Fedora Community dashboard

https://admin.fedoraproject.org/community/#package_maintenance/updates/testing_updates

Using the fedora-easy-karma tool

Fedora Easy Karma

Questions and Answers

1. Q: What versions of Fedora and EPEL use or will use Bodhi? A: Fedora utilizes Bodhi as of Fedora 7. EPEL now utilizes Koji and Bodhi.

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, see Advantages of Bodhi.

4. Q: Is there a command line interface to bodhi? Do I have to have web access? A: The bodhi-client package is available.

5. Q: I want to push my package directly out, bypassing testing. A: You need to get permission from FESCo for this.

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 stabilize 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.

8: Q: How fetch really new Fedora packages with Bodhi ? A: bodhi updates download --updateid FEDORA-2018-42024244f2 or bodhi updates query --packages rust --releases f28 --status pending; bodhi updates download --builds rust-1.28.0-2.fc28 more details on https://utcc.utoronto.ca/~cks/space/blog/linux/FedoraBodhiGetPackages

Outstanding Questions

Enhancement suggestions

Proposed addition to New on the need and steps for ensuring that a package and its dependencies are pushed together as one unit.

There are cases where a package depends on one or more other packages and one must ensure that the package along with the packages it depends on are pushed to stable, or testing, as one unit. If the dependent package gets pushed ahead of the others this would cause unresolved dependencies at update time.

To give a concrete example: nss was split into three stand-alone packages, nss, nss-softokn, and nss-util. nss depends on nss-softokn and both nss and nss-soktokn depend on nss-util. They all, in turn, depend on nspr. nss-softokn is updated independently of, and less frequently than, nss whereas the nss-util package is usually updated in synchrony with nss. If several of these are updated they must be pushed as a unit.

Via the Bodhi Web interface: At the point of adding our package build to the update, add also any rebuilds of packages this one depends on. This ensures that the package and its dependencies are submitted as one unit.

Via the command line interface: you can do it also by adding all needed builds

If the package has a dependency on another package maintained by someone else one still make a bundle, e.g., Firefox, xulrunner, and the nss packages are sometimes released together as a "bundle" in Bodhi.

Ideas for improving the Karma System