On Fri, May 26, 2000 at 09:21:42PM +1000, Anthony Towns wrote: > On Fri, May 26, 2000 at 06:44:28AM -0400, Branden Robinson wrote: > > On Fri, May 26, 2000 at 01:32:01AM +0000, Lars Wirzenius wrote: > > > 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. > > dselect might not behave correctly with non-US packages being standard, > and boot-floppies might not cope. The non-US CD scripts might not put > non-US/standard in the right place, or might die horribly. I'll leave such assessments to those who know. I'm arguing against the principle of Lars's argument, not this specific application. I'm not going lose any sleep myself if ssh is not made standard. I've already got it installed. > > Come on now. Let's not take a superstitious attitude towards our packages. > > They aren't magical. > > No, but they are complicated enough to have implications that are > difficult to predict in advance. That's why we like having some time to > test that everything works as we expect before we claim they're "stable". Yes, and we're starting a new test cycle c. Monday. > > Likewise, modifying package descriptions or other slabs of non-executable > > documentation -- or comments in code -- cannot reasonably be expected to > > cause problems. > > But, of course, they could. It would, for example, require the source > package to be rebuilt for all architectures, which might reveal a probelm > with the build environment on some autobuilders, which might in turn > require a change in the build depends, or the package to be updated for > new library versions (if the last version was compiled on glibc2.0, eg). > > Now sure, this is a definite Good Thing most of the time, but it's *not* a > good thing right at the end of the freeze. We're not *at* the end of the freeze. We've finished one test cycle and we're starting another. > > 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. > > No, a freeze is for fixing problems, not introducing new ones. You're begging the question. > You've had, what, four months of freeze to fix these silly bugs, if > you're not done now, it's *too late*. Wait for woody and fix them then. What's all this "you" talk? You want to talk to me about my bugs? I haven't had four months to fix the X server TCP port DoS attack problem, because it was only brought to my attention within the past week. I intend to release 3.3.6-7 with a fix for this, another DoS, and 6 RC bugs this weekend come hell or high water. You are free to campaign with dark to prevent this release from being accepted into frozen. But I've already spoken with both he and Wichert about it, and they seem to think it's a good idea. If I fix a spelling or grammatical error in debian/copyright while I'm at it, I challenge you to justify the package's rejection. The gauntlet is down. Try and stop me. If you succeed, it will be to the detriment of our users. > The closer we are to releasing, the smaller the changes we should be > making; right now we shouldn't be making *any* unnecessary changes > *at all*. No. The closer we are to releasing, the more carefully we should consider the impact of the changes we do make. If a big ugly critical bug shows up in an important package that requires a 100 line patch to fix, well, then, we'd better test the hell out of it. You seem to be arguing that bugs come to a package maintainer's attention through some volitional process of his own. If he's responsible enough to read all his bug reports as they come in, this is impossible. Bugs get found. They're not going to stop cropping up because we decide it's time for us to freeze. [...] > aj, who'd've thought Branden would've been much more timid about > apparently innocuous changes around the freeze after the X split. Maybe if you understood the history of that event you'd be less inclined to speculate thus on my reasoning. The Great X Reorganization was hell because I made a deliberate decision to get the reorganized packages into slink right before the freeze, even though I hadn't gotten them into a state I could live with yet. I wasn't in charge of scheduling the freeze, so it was time for me to sh!t or get off the pot with regards to the package I had adopted. I elected to sh!t, with consequences that were stressful, and foreseen, but turned out all right. It *wasn't* because I was reckless with the changes I committed to the X packages *after* we were in freeze. All the above said, it would make the release manager's job easier -- and help us avoid unexpected problems in packages -- if most developers were at least as meticulous about documenting their changes as I am, but hoping for that is probably pretty pointless. -- G. Branden Robinson | Software engineering: that part of Debian GNU/Linux | computer science which is too difficult branden@ecn.purdue.edu | for the computer scientist. roger.ecn.purdue.edu/~branden/ |
Attachment:
pgpoXFdGFkR1N.pgp
Description: PGP signature