On Sat, May 27, 2000 at 03:29:16PM +0000, Lars Wirzenius wrote: > I don't advocate superstition or mysticism, but I do advocate caution. > > It's OK to fix things during a freeze. Of course it is. It's also good > to be painfully aware that every fix needs to be tested. The Debian > packaging system is complex enough that even small changes can have > unforseen consequences. Thus it is not enough for the *package maintainer* > to test it - everyone else needs to test it as well, during the next > test cycle. > > I especially don't want non-release manager ftp admins to muck around > with the freeze on a whim. > > For each change, one needs to weigh the effect of the change against > the potential risk of further complications. At some point, one just > has to decide to stop worrying about small things, to stop changing > things, so that one can release. > > (I'm not arguing the specific case of ssh, just the general attitude.) I agree with all of this; I also do not see how it translates into a policy that I can't fix non-RC bugs if I have to do a release to fix RC bugs as well. > > you know how comments work in C. They go away during compilation and don't > > impact the object code. > > Real-life examples: > > Documentation comments that are extracted by a tool and you break > the markup syntax. The package maintainer should know whether this happens to his package or not. In most cases I would expect this kind of extraction to be part of the package build process, so if you fuck it up, the extractor will bomb and you'll know your build is busted even before the .debs are created. > Version numbers are embedded in and automatically extracted from comments > and you make the version wrong. And this introduces breakage how, exactly? > Inadvertently nesting comments, because you make a typo in the comment > terminator. Will cause a compile-time problem. The package won't even make it out the door. > Using a newer comment syntax than all target compilers will support, Will cause a compile-time problem. The package won't even make it out the door. > and not noticing it because you haven't got access to all of them or > you use a different configuration. I think you exaggerate the likelihood of this kind of problem in our build environment. We do not have wild version skew in the versions of gcc used with our supported architectures. > Oh yes, changing a comment can indeed cause problems. Not very often, > but if you're striving for quality, you *will* have to test even changes > to comments. Sure. But we have to expect maintainers to exercise some judgement, or we might as well not have maintainers at all. Rattling your saber about changes to comments (you haven't addressed plaintext docs that don't get processed by some other tool, which is another thing I feel at liberty to change in my own packages regardless of freeze) seems like a slippery-slope argument to me. > > Of course it is possible for *unreasonable* ramifications to manifest; for > > instance, I could add some code to the xfree86-common preinst like this: > > I'm not worried about unreasonable ramifications, just unforseen ones. Then we'd better bring development to a halt. If a maintainer does something stupid, he needs to be LARTed. If he doesn't, and something blows up anyway, sometimes we just have to accept the casualties. -- G. Branden Robinson | Kissing girls is a goodness. It is a Debian GNU/Linux | growing closer. It beats the hell out branden@ecn.purdue.edu | of card games. roger.ecn.purdue.edu/~branden/ | -- Robert Heinlein
Attachment:
pgpIJ3Qq3YXNO.pgp
Description: PGP signature