Hi all,
I thought it would be good to start some discussion on $SUBJECT before our next
meeting.
As already said in my mail proposing to do more reviews of patches, I've
noticed that we have lots of regressions, esp. in rawhide, which seem to be
avoidable, thinks like making a typo in a variable name etc. (Man I miss C's
compile stage here, that would catch all those).
So I've been thinking about this and talking to various people about this and
there are a number of things I would like to see us do, basicly it boils down
to 2 different things:
1) Do Reviews
2) Do a lot more automated testing / checking
1. Has already been discussed, so lets take a look at 2. My plans for 2 are:
1) Run PyChecker and fix anaconda sources where necessary to make PyChecker
happy
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).
The only argument against doing whitespace cleanups is
that it makes porting patches between RHEL-5 and rawhide harder, well that is
usually a job which needs to be done manual anyways, and as the code diverges
more this becomes ever more true.
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).
Some people will probably not like this, and to be honest, I don't care. Go
clean up your act. This is just like people ignoring "gcc -Wall" warnings, I've
been a Computer Science teacher for too long and as such have seen to much
failing code where the compiler warned it was valid C but not good C, which
probably did not do what the programmer wanted, and the compiler was right.
After being a CS teacher for 10 years I've heard every possibly excuse to
ignore whatever warnings and every single excuse was lousy!
Sorry if I sound a bit harsh here, but currently we are doing a not so good job
at pre-build / pre-commit QA, and I don't want to spend all my time fighting
push back for changes which will benefit us all in the end (I much rather spent
my time actually making these changes).
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
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.
And yes again my proposal is to fail the build if any of these checks fail.
5) Maybe do unit tests for some parts of anaconda
Thats about it for now more suggestions are very much welcome! This is all
intended to be put in to place (in as far as its ready) at the beginning of the
F-11 cycle.
I'm also thinking about running PyChecker on RHEL-5, the idea is to generate a
list of all currently present warnings / issues, store that and when a new
build is done rerun PyChecker and compare the results. Any *added* warnings
will then fail the build. We might even start with doing things this way for
Fedora, so that we can slowly clean things up.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
