Jeremy Katz wrote:
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.
I'll checkout pyflakes too.
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)
pychecker can be passed a list of modules to ignore.
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.
Hmm, to me this feels more like a kludge the something desirable.
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.
Could do, but that is going to be pretty slow, and to me this does not feel
right. We do want certain packages IMHO, not certain files, but the keepfiles
list is a hack to work around some packages not being split up fine enough IMHO.
Which make me think, that maybe we need both a keepfiles and a removefiles list
and error out if:
1) a file on the keepfiles list is not found
2) a file on the removefiles list is not found
3) a file is installed by yum which is in neither list
This way we can quickly detect any package changes and see what we should do to
adapt.
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.
Nobody is stopping the person from submitting the build, to actually watch it
progress, check for errors, fix then and resubmit the same day.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
