* To complete the TG1->TG2 port, bodhi's widgets, controllers, and templates need to be ported

* To complete the TG1->TG2 port, bodhi's widgets, controllers, and templates need to be ported

* Pyramid resource traversal has been written ([http://git.fedorahosted.org/git?p=bodhi.git;a=blob;f=bodhi/resources.py;h=6d15cadf1ae749fd462d519d399286106c84ad86;hb=refs/heads/pyramid bodhi/resources.py])

* Pyramid resource traversal has been written ([http://git.fedorahosted.org/git?p=bodhi.git;a=blob;f=bodhi/resources.py;h=6d15cadf1ae749fd462d519d399286106c84ad86;hb=refs/heads/pyramid bodhi/resources.py])

Revision as of 19:51, 27 May 2011

This is a draftThis is a draft of potential features for Bodhi v2.0. It is meant to spawn discussion and will most likely evolve in the future. Please feel free to add your ideas, comments, and criticism to the 'discussion' section of this page.

Goals

Painless update submission

At the moment we have an auto-completion widget that aids in the creation of new updates from the web form. With bodhi v2.0, we wish to take this a step further and make it even easier to submit new updates. This could be done in a variety of ways: from providing a list of your candidate updates, to being able to clone existing updates, or by making it simple to submit full 'stack' updates (e.g: firefox & related deps)

Policy Knobs

As opposed to hardcoding policy logic into the system, every aspect of bodhi 2.0's update policy will be exposed as configuration options which will allow us to tweak them as we see necessary without any code changes.

Make it clear *exactly* what has changed in each update, from spec file changes to full code diffs.

AutoQA integration

Bodhi v2.0 will provide tight AutoQA integration, allowing us to require AutoQA results in our policy, and making it simple to view results and such.

Better security features & workflows

Improved CVE handling and tracking

OVAL metadata creation

Improved metrics

Interactive graphs

Metric reports

Message bus integration

Bodhi v2.0 will offer AMQP broker integration. This means that upon various events, bodhi will send notifications to a central message broker, allowing clients and other services to react to them accordingly.

It will also be designed to potentially listen for events that our infrastructure may send out in the future, such as when a new koji build completes, or when AutoQA finishes testing an update, etc.

Improved database model

Porting from SQLObject to SQLAlchemy

Migration tools will for our schema to easily evolve over time

Will allow us to perform more sophisticated and efficient SQL queries, thanks to features such as eager-loading

Release phases

Bodhi v2.0 will become aware of the various release phases. So, when an upcoming release branches from rawhide, bodhi will automatically know to enable the "No Frozen Rawhide" policies. When a release goes EOL, bodhi will know to freeze it, while still making the data easily available and accessible.

Bodhi v2.0 will also become more flexible with handling different releases, such as Fedora and EPEL, which have different policies.

i18n

TG2/Pylons makes it very easy to make your application internationalizable.

Improved exception handling

Right now exceptions propagate to the bodhi logs, but there is no proactive measurements that notify us of errors as they happen. The WebError middleware that comes with TG2 will email us upon every exception and offers a rich traceback debugger that we can use even after the exception has occured.

Optimized push process

The current push process within bodhi (aka The Masher) does a lot of work that can be done in parallel. The next version will effectively scale to multiple processors, prioritize critical/security updates, and sync each release to the mirrors once it is complete (as opposed to waiting until all releases are complete)

There are a variety of race-conditions that can occur with the current push process. Bodhi v2.0 aims to eliminate these, potentially by locking updates when they are being pushed, or by some other means.

Fedora agnostic

Bodhi is currently used in many places outside of Fedora. One of the goals of v2.0 is to make it much more flexible for people that aren't within a koji/pkgdb/fas/bz environment.

Well tested and well documented RESTful API

Will retain backwards compatibility at the JSON level and within python-fedora.

Ported from TurboGears 1 to 2

Will benefit from many speed enhancements and architectural improvements