On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote: > but you can't file 1060 RC bugs at the beginning of a freeze.
Why would you want to? File 1060 normal bugs before the freeze! (If you must file 1060 bugs at all -- I hope that's not a habit of yours.) If we want, we can adjust the severity at freeze time, when, hopefully, many of those bugs will have been closed. Or we can say, "there's just too many left open, realistically, we'll have to leave this for the next release." And you still seem to be implying that filing bugs fixes things. I may have to retract my earlier apology. Filing RC bugs _is_ asking for packages to be removed (especially this close to a freeze) unless you're planning to NMU if necessary, or know for a fact that someone else *will* fix the problem. Saying "oh, it'll just get fixed at the next bug-squashing party" is a seriously irresponsible attitude, IMO. For a problem affecting that many packages, I'd rather tackle policy and see about getting a change that would allow those packages to remain in the system for a while longer. > > Note that the next paragraph mentions filing bug reports if the > > package becomes "too much out of date". If any is too much, why > > bother to say "too much"? > You mustn't have to upgrade the Standards-Version field when your package > doesn't comply with a more recent policy -> a package that doesn't follow > FHS will never rech Standards-Version 3.0 . I'm having trouble parsing that. It sounds like you're saying that you think it means that if a change in policy does not affect your package, you *must* reupload to change Standards-Version immediately or it's an RC bug, but if a change in policy *does* affect your package, then you don't have to reupload, and it's not a bug at all? That would be insane. Policy is not the word of God. It's our feeble attempt to codify what we consider to be best practices. And it needs to be read in that light. If your interpretation of policy leads to an insane conclusion, it's time to ask for a clarification or correction, not to blindly engage in insane behavior. > > Bottom line, I think there remains a lot of work checking the subtle > > and not-so-obvious stuff in the FHS before we can confidently claim > > FHS compatibility (and even *begin* to work on actual compliance). > Reading the last three sentence I'm glad to hear that you volunteer to do > all this checks... I'm not the one who came here saying, "I want to suggest to finish the FHS transition." And I'm not the one who came up with a simple two-step plan which fails to achieve that. Yes, I have been working on the issue. No, I probably can't do it alone. If you don't want to help, that's fine. But when someone who has been studying the issue for the last year tells you that it's not so easy, maybe -- just maybe -- you should consider listening. cheers -- Chris Waters | Pneumonoultra- osis is too long [EMAIL PROTECTED] | microscopicsilico- to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
