On Fri, May 26, 2000 at 01:32:01AM +0000, Lars Wirzenius wrote: > Nothing can go wrong with only changing a comment or a string literal in > code, right? Being conservative with changes during a freeze is a good > policy. Not meddling with the parts of the archive that are the release > managers responsibility is also a good policy. > > No, I don't know what could break if ssh's priority changes. I do > know that something *might* break and that's enough justification for > Antti-Juhani, who is not the release manager, not to touch it in frozen. Come on now. Let's not take a superstitious attitude towards our packages. They aren't magical. With a little knowledge and thought it is easy to distinguish changes that can reasonably have ramifications and those that can't. One can err on the side of caution without abandoning one's package altogether. What in our system actually uses package priorities to any functional end? All I can think of is lintian, and all it does is generate reports. Before making such a change (or, rather, before asking the ftpmasters, who control the overrides file -- which is what really counts -- to make such a change), I should research the possible consequences. But if there is no reasonable expectation of breakage, one should be permitted to go ahead. Likewise, modifying package descriptions or other slabs of non-executable documentation -- or comments in code -- cannot reasonably be expected to cause problems. Modifying a string literal in C code -- especially if you change its length -- is not really a fair comparison, as much code will clumsily make hard-coded assumptions about the length of such literals elsewhere. But you know how comments work in C. They go away during compilation and don't impact the object code. Of course it is possible for *unreasonable* ramifications to manifest; for instance, I could add some code to the xfree86-common preinst like this: if [ "$(zcat /usr/share/doc/dictd/README.Debian.gz | wc -w)" != "685" ]; then echo "Venus is not in the house of Pisces!" exit 246 fi So what if the dictd maintainer changes the number of words in his README.Debian file? The fault is *mine*, not his, because my package has no business depending on such a thing. We can't take a pussyfooting mystical attitude towards the freeze that prevents us from making minor changes that improve the quality of our distribution. Especially in the documentation department. *Of course* these things are judgement calls. That's why you note your changes in the changelog for the Release Manager's review, and why you TEST your packages before uploading them. But placing a categorical ban on non-programmatic changes out of fear that you'll uncover someone else's irresponisibility is just plain stupid. We should be shining the light on such roaches, not letting them lurk undetected in our distribution. A freeze is for fixing problems, not covering them up. -- G. Branden Robinson | The errors of great men are venerable Debian GNU/Linux | because they are more fruitful than the branden@ecn.purdue.edu | truths of little men. roger.ecn.purdue.edu/~branden/ | -- Friedrich Nietzsche
Attachment:
pgptJ4bb6M53q.pgp
Description: PGP signature