seth vidal wrote: >> * Switch from cvs to git > > is git the clear winner on the distributed SCM wars? I always lose > track.
Yes. I'd be happy to say why and to give examples of how to use it for day-to-day yum stuff, if anyone wants me too. Otherwise, I'll keep the zealous ranting off this list. >> * Add more unit tests, specifically for sqlitesack and depsolve. > I'd be curious how to do the depsolve unittests. I'm not sure I know > of a good way to ensure coverage. depsolve.py is only a part of depsolving, right? So we have tests for sqlitesack and possibly rpmsack to verify their behaviour, then we test depsolve.py on its own, using in-memory fakes for the rpmsack and the sqlitesacks, this way we can set up the exact conditions we want to test. Unlike git, these tests will not be a panacea. We still might want something akin to the automated performance tests, running against real rpmdbs and sqlitesacks, and verifying the output. > > >> * Hook up getUsage and the HelpCommand > ok. Is there something keeping this from happening, now? Nope. I've got half finished patches for it, too. I just want to finally get it done :) > > >> * Get a more generic callback.py into yum for other apps to use, with >> hooks for progress callbacks, etc. > > progress callbacks into what? The transaction or do you mean an overall > callback for something yum is doing? So this is a philosophical thing, I think. Tim mentioned the code that exists in Yumex at http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/yumex/src/yumgui/callbacks.py?view=markup I believe this should be done with composition, rather than inheritance. There should be only one RPMCallback class, that optionally can take as a parameter another object or group of objects which it then delegates to for all the progress callbacks. This way the RPMCallback class is only worried about the RPM specifics, and the other class is only worried about printing, or moving a progress bar. Either way would be nice though, since that callback class is duplicated everywhere. -James
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
