On Fri, 2008-10-24 at 11:12 +0200, Hans de Goede wrote: > 1) Run PyChecker and fix anaconda sources where necessary to make PyChecker > happy I'm not sure that pychecker is the best choice. Looking at pyflakes might be better. We actually used to run pychecker regularly but after either a pychecker or python upgrade, the number of non-problems that it flagged as "problems" due to not really handling the logic was ... huge. Maybe we're to the point that we can actually have somebody spend some time fixing pychecker/pyflakes if they are still in horrible shape. > 2) Use python -tt, this will require whitespace fixups, but I've heard > grumblings about our inconsistent whitespace usage from various sources, we > even have bugs opened about this (which I can't find right now, but they exist). Probably worthwhile > 3) Add a "make test" target which calls PyChecker and possible does other tests > and add "make test" as %check to the spec file. > > Yes this means that having something which PyChecker does not like will break > the build, this is intentional. Its better to have an old working build (with > known bugs) in the tree for a day longer, then it is to have a new build which > has known new issues (potentially of the will not install at all type). The only reason I see for not doing it at build time (and failing the build) is that we end up getting the errors from packages we don't control potentially failing our builds. gcc -Wall -Werror we've done for a long time because everything there is "our" fault... but pychecker, etc will also fail due to errors in pygtk (or $insert_other_python_module_we_use_here) > 4) Add more automated validation in the build process where possible, for > example we've been seeing quite a few bugs in rawhide due to fonts going > missing. There are 2 things which I want to do here: > a) Verify that all the packages which we ask yum to install into the install > image root, actually have gotten installed We (intentionally) keep old and new package names in the list so that we are slightly flexible about the environment in which we're used. > b) Not only keep files on the keep list, but also check we actually have all > the files on that list in the root, so that if files get moved to a subpackage, > etc. We *automatically* catch this at the first build. Arguably, we should move to just telling yum to install packages by specifying the files and not the packages. > And yes again my proposal is to fail the build if any of these checks fail. Failing the rawhide build for something like this is somewhat counter-productive. Sure, it points to the fact that a Japanese font changed. But the downside is that it means that we can't get testing of anything else that day. Which, since many of these sorts of things are out of our control, basically means that we don't get to do our testing some non-trivial percentage of the time. Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
