On Wed, Dec 11, 2002 at 10:23:14PM -0600, Steve Langasek scribbled: [snip] > > code to test for missing /etc/postgresql/postgresql.env and restore it if > > necessary - the bug was precisely in that code, which was never tested after > > adding it. And in this case the test was trivial, really trivial - it was > > sufficient to either move said file out of the way or install the whole > > thing in a chroot. > > Your initial criticism was directed at maintainers who did not install > their packages before uploading, or at maintainers who did no testing of > their packages at all before uploading. Though the testing required to Yes. > catch this bug is trivial, it is not always obvious to a maintainer when > more testing is needed, or *what* testing is needed -- or what changes Come on (I will stick to the postgres example) - if I add a test for a missing postgresql.env file then it's fairly obvious I have to remove that file and test the code. If the package breaks after installing it because of a programmatic error in the software itself, fine, we will cope with it. But, for all saint's sake, may the package install at least! Every single maintainer should test any change to their packaging scripts. Every, even the smallest change. And lack of time is not an excuse here because you rarely change large chunks of code in those scripts. If the test case is unclear then I agree with you, but cases like that missing postgresql.env or mozilla incorrectly calling an external script are painfully obvious -- those packages should never hit even experimental. > will require more testing. An excellent maintainer will test each > change thoroughly by testing that specific feature in the live package. > Sometimes, it isn't even obvious what the possible side effects are, > though. Agreed, but it's not the case in this instance. > > > In reading the bug report you linked to, I understand that Oliver is > > > claiming that he did install the package to test it. I haven't looked > > If he did so, he must've noticed that the previous version of postgresql-dev > > package has had a bug in its .postrm script - a bug that could've been fixed > > in the newer version of the -dev package _if_ the newer version was ever > > installed. To cover my words with facts, here's the .postrm script from the > > buggy version (typing from memory, the path might be wrong): > > > #!/bin/sh > > rm -f /usr/include/postgresql/libpq++.h > > Do you mean > > rm /usr/include/postgresql/libpq++.h > > ? The command you quoted has '-f' in it, so it will always succeed. Yes, with out -f, of course. > > > Maintaining a large server package like postgresql isn't easy, and I > > > don't think we have enough developers who are willing to work on this > > > kind of package. I don't want the developers we *do* have working on > > > large packages to feel unappreciated and abandon them. > > Oh, but that's not my intention. As I suggested twice alread - if time is > > the issue, find helpers! And postgresql has been giving us many problems in > > the past year or so. Therefore I do think that Olivier needs help - but > > nobody can push him to ask for it. > > Easier said than done. Where do you look to find helpers if none > volunteer? That's the question, I think. First you have to look at all. If you don't find, only then you can wonder where to look more. None of the maintainers mentioned in this thread ever sought for help (at least I don't recall them doing so in public). Neither you or me can write a mail with the plead for help, they would have to do it. marek
Attachment:
pgpVvKdVwSD8z.pgp
Description: PGP signature