On Fri, May 26, 2000 at 10:49:10PM +1000, Anthony Towns wrote: > > 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. > > Note that the hypothetical problems I listed don't apply in this case: > any problems a documentation change might cause will happen anyway > because of other necessary changes to your package. And it's been > Richard's philosophy throughout the freeze to allow such changes. > > My previous message was talking about package updates to fix minor bugs, > and with no other changes. That may be what you're talking about, and if so we agree -- but it is not what I understood Lars to mean. > > > 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. > > Eh? > > ] Because it's too late. They've already been renamed. If I had > ] appreciated the difficulties this would have caused me four months > ] ago when I first drafted my proposal, I would have renamed only two > ] packages -- xbase and xfntbig. I would have let the rest wait for more > ] support infrastructure from our packaging system. I was much less > ] aware of dpkg's limitations at the time. > > From http://www.debian.org/Lists-Archives/debian-devel-9901/msg02123.html I don't see how this contradicts what I said. My remarks above have to do with decisions I made while slink was unstable, not frozen. Likewise, this thread has to do with package uploads that occur during freezes, not periods of avowed instability. > What I meant by the above was that unforseen problems can and do fuck > things up royally. Examples from this freeze seem to be xchat and epic4 > which had a run of new upstream versions that surely couldn't have caused > problems, that did, repeatedly. Then the maintainers should have been taken to task for breaking the rules. Sometimes a maintainer gets stuck between a rock and hard place, though; as in the cases of security fixes that cause upstream revs. What's worse, the time consuming and error-prone process of backporting a patch yourself, or running the risk of fresh upstream bugs mixed in with the security fix? This is an especially bad problem when upstream doesn't have good change documentation practices, either (so you can't tell the security-related changes from other stuff). > Similarly, unseen problems in the Great X Renaming caused it to blow > out into a much bigger issue than it had any right to be. I still don't think the Great X Reorganization is a good example of a maintainer violating the freeze policy. I made a deliberate mess[1] while slink was unstable so I could use the frozen period to clean it up. If there is a problem with that, it is nevertheless a distinct sin from violating the freeze policy. [1] Well, not exactly. What I did was release a package with known big problems because if I spent longer cleaning up, the freeze would have been in place and then I *couldn't* fix them for the forthcoming release. -- G. Branden Robinson | If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot branden@ecn.purdue.edu | support the government. roger.ecn.purdue.edu/~branden/ | -- anonymous
Attachment:
pgpqM7zTSuirU.pgp
Description: PGP signature