lmacken 
Bodhi


FC1-FC3
Add builds to a cvs file.  ping releng.  releng uploads and creates repositories manually

FC4-FC6
Internal to RH updates program
Fedora Core only
mod_python, no ORM, no templates.

updateinfo.xml and modifyrepo tool created and used.

Was lmacken's first python project.

Had a BeOS look and feel

After Zod - core extras merge.  Rewrite of the internal tool: bodhi

Used TG1, things that were awesome at the time
Streamlined the workflow
Karma

Lead to having a Generic Client that could interact with all of our TG1 apps.

7 years in production now.



push process.  Mnay steps.  quite ocmplex.  Bodhi 2 to ismplify these steps.

Bodhi keeps statistics.

TG1: a lot of the tech has disappeared upstream.
Complex identity management that doesn't give enough information about it's errors
inflexible db model
+1/-1 karma.  Want something more flexible
race-conditions.

Over the years, have had serious bugs that had to be fixed:
Duplicate IDs for updates due to bugs.  Lead to links not going to the right place.
f9, newkey -- had to resign a bunch of packages without rebuilds
sha256sum updateinfo didn't have a sum in the name.  Fixing this caused rhel5's yum to be unable to update due to a dep from yum to python-hashlib which was in updates.

= bodhi2! =

Post-f21 so that we aren't too disruptive until after F21 and the zero-day updates.

* Better look and feel
* Fedora bootstrap plugin.
* restish api:
* pyramid.  cornice which autocreates documentation for the REST api.
* Can hit endpoints for html/json/rss output.
* cli interface is better.  the click library.  Decorate methods with the options that were given to it.
* Search is better.  autocompletion which is categorized, a bit faster.
* bodhi1 notification emails *a lot*  bodhi2 will use fmn (fedmessage notification).
  - Go to fmn to specify what messages to receive and how to receive it (email or irc or other)
* datanommer and datagrepper data mine fedmsg.  We use it to create a topical newsfeed for bodhi/updates information.  For instance, includes how many packages were changed in the mirrors.

* Better debugging/profiling tools -- what sql is used for any given page view, profiling hotspots,

* SQLAlchemy w/ alembic (for migrating schema)
* pyramid w/ cornice
* colander for validation of data we're accepting from the users.
* fedoauth for openid authenticating
* OpenID Baseclient for the new CLI.
* The Masher is now kicked off by fedmsg consumer

DB Model now can keep track of testcases as a URL from the wiki and test results.  More timestamps as to when things happen.  More flexible karma.

benefits to testers:
automated test integration with taskotron.  Separate from comments
On the front page, priority listing of critpath and security updates for testers to target
widget to show the week's top testers.
badges for things that you do in bodhi.

Hoping to encourage testers and to encourage them to do things that help out hte distro more.

Comments/karma can be categorized in various ways: per-testcase, per-bugzilla bug, additional bugs that aren't part of the original points of the 

fedora-easy-karma and fedora-gooey-karma written by QA people.  Good, will need updates to use the new features of bodhi2


Package maint can autofill bugs and changelog.
can now have customizable karma requirements.
- ensure that hte update fixes specific bugs or passes specific testcases before going to stable.

- faster updates: masher optimizations, easier karma from community. more reliable auto test, hopefully fedmsg => mirror integration
- hopefully will make updates better tested.
        
- modern framework should hopefully be easier to hack on.
better separation between api, validators, views.
better test suite with good coverage.
easier to run locally for testing.

Action items:
* Where are we going to mash (take the packages tagged in koji and make it into a new repo -- multib is a major part of this)  Hope to do the is in koji
* taskotron integration.  The taskotron widget seen earlier needs to be created.
* per-update finegrained karma needs to have a UI written.
* Port python-fedora's client API to bodhi2.

The Future:
* Better dep handling
  - taskotron will check for broken deps.  Hope to ask taskotron at push time, taskotron tells us via fedmsg if deps are good.  then push.
  - streamline grouping of full stack updates
* Monthly bundling of updates
* Changes for fedora.next
  - to push ami's through bodhi.  Bodhi just needs it to be taggable in koji
  
  
Why use pyramid instead of django:  SQLAlchemy.  Pyramid is easier to customize than django.  django not great with distro packaging.