[Yum-devel] beyond 3.0.X

[seth vidal]

On Fri, 2006-12-01 at 11:05 -0500, James Bowes wrote:
> seth vidal wrote:
> > Hi guys,
> >  I'm looking around for things beyond 3.0.X to do in yum and I'm mostly
> > seeing improvements in various things that are really just evolutionary
> > changes. Enhancements but nothing major. I'm curious if maybe I'm not
> > seeing enough so I'm curious what other people are interested in doing.
> > 
> > Right now I'm interested in:
> >  - speeding things up where possible
> >  - making sure we can simplify writing other tools using yum
> >  - robustifying portions of the code for failures
> >  - enhancing our error reporting
> > 
> > What do y'all think matters?
> 
> I love that yumcommands.py, so I'm looking at filling in the help for 
> each command, and maybe tab completion in the shell. Though I suppose 
> that could go in 3.0.X as well?
> 
> On the subject of performance, it might not be bad to focus a release 
> purely on code tuning, with a clear set of goals. It seems to be working 
> for Bazaar.

In a sort-of-related way we should go through and makesure we
de-pkg-tuple the code as much as is possible.

rpmUtils.updates could possible be converted over to pkg objects and/or
that whole piece of code be brought into the yum module hierarchy and
cleaned up. I understand why it was originally in rpmUtils, that was
when I had some delusion that other tools would use rpmUtils but not the
yum modules. As it seems now no one uses the rpmUtils unless they're
using yum so there's no eventual reason why we shouldn't trundle pieces
over to yum as a migration/update path w/o breaking the older mechanism
simply by letting it sit.

This code also needs unittests.

Where are we obviously slowing down? We know about the rpmdb reading
slowness and we'll probably do _something_ to fix that up. What's the
next slowest section? From what I've seen the updates above needs some
look for trimming down or optimizing.

other suggestions?
-sv