[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Improving our development process

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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]