Did you ever find yourself in trouble because an update to an application would cause your users to fail in whatever it is they do? Note that this ranges from actual users with business applications all the way to girlfriends having bought a book written for a specific version of the GIMP or Blender. Or did you ever find that certain systems just won't boot "kernel du jour" as I like to call it -although obviously Fedora does not release yet another kernel every day? Or, would you just like to have an inventory system to see what applications are installed on any given system -and manage the updates? Sick and tired of coming up with wrapper scripts around the rsync command so that you can sync a complete mirror?

I'd like to share this idea I have, with you. The SUMS Update Management System (SUMS). Being named SUMS for several reasons I won't go into right now, here's the basic idea:

1. A webinterface let's you configure (for those with ITIL: IMACD) a number of distributions
2. With these distributions you configure (same IMACD here) a number of repositories
3. These repositories have a (set of) baseurl(s) and/or a mirrorlist for clients to use, and some setting that let's the backend know where it can sync data from
4. It polls for new packages every once in a while and let's you specify the acceptance level (in testing, approved, blocked)
5. Clients report what they have (so that you could potentially optimize syncing), and hence you have inventory
6. Clients poll for updates or package actions (in the "to be installed" or "to be removed" category)

I've played with this idea for some time and actually came up with a web interface in TurboGears using Kid that would sync repos and let you move packages to testing, and approve or disapprove them. To take it to the next level, I need your help.

I'd like to think about:

1. Letting the web interface actually serve the packages (either http redirect to a mirror upstream or by syncing and serving the actual RPM files)
• with regards to the status of said package
• with regards to the "access level" of the client system
  
2. Integrating the web interface with a Source Control Management system to be able to sync YUM .repo files you can then roll out with puppet (sorry, don't like CFEngine)
3. Getting in a patch for MirrorManager to enable it to return lists of mirrors by protocol (sorry Matt, we've briefly discussed this during FUDCon in Raleigh, I know; I just haven't come around to actually do it)

If you have additional ideas about what it can do I urge you to drop me a line stating what idea you have, and if you have some vague idea of how this could work, again, let me know.

I'll be at FUDCon in a few days, and at the Red Hat Summit also (for obvious reasons) - if you are there too, come and walk up to me and share ;-)