On making "it can't break" type of changes during freeze
Branden Robinson <branden@ecn.purdue.edu>:
> 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.
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.)
> 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. Version numbers are embedded in and automatically
extracted from comments and you make the version wrong. Inadvertently
nesting comments, because you make a typo in the comment terminator.
Using a newer comment syntax than all target compilers will support,
and not noticing it because you haven't got access to all of them or
you use a different configuration.
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.
> 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.
Anyway, Anthony Towns said this better than I did. :)
--
Brannigan's Special Ale, anyone?
Reply to: