[Fedora-infrastructure-list] New OTRS Queue: Update System
lmacken at redhat.com
Fri Jul 28 16:11:49 UTC 2006
On Fri, Jul 28, 2006 at 10:32:07AM -0500, Mike McGrath wrote:
> I've added a new OTRS queue for the Update System. Any users wishing
> to monitor and aid in troubleshooting Update System problems should
> add this queue to their "my queues" section in OTRS.
Thanks Mike! Speaking of the update system..
In my spare cycles I've been working on a new version of the currently
internal update system using TurboGears. This time around, I hope to
weed out all of the nasty mod_python hacks and hopefully add some
cohesion between the Core/Extras/Legacy package update process. This
will entail a web front end for adding/viewing/maintaining updated
packages and viewing metrics, with an xmlrpc api which can be used by
command-line tools, and most likely per package/distro/whatever RSS
I guess now we should start figuring out where this stuff is eventually
going to live. If no one has any problems, I can import the code I've
been working on into svn. Since TurboGears is badass, it has the notion
of a development environment and a production environment, so testing
the server in a dev environment is as easy as ./start-updatesys.py on any
machine w/ TG. The production environment we can worry about later.
This brings us to the Package Database, which the Update System can tie
into nicely. I currently defined a Package and a Release table in my
current model.py which defines the basic fields that the update system
needs, but expanding to use Elliot's db model would be trivial.
So what progress, if any, has been made on the package db? Being fairly
well-versed in TurboGears, I'd like to help out a bit. If it hasn't
already been done, I can create a default TG layout with Elliot's model
in place so people can start poking around with it.
Before much code gets written I think we need to figure out what this
'Package Database' is going to offer from a front-end perspective. Does
it need to be it's own entity? Can it be tied in to the update system to
provide a one-stop-shop for all fedora package related shenannagans?
But in the mean time, getting whatever code is written into a place
where we can all start poking at it is probably a good first step.
More information about the infrastructure