Re: Finishing the FHS transition
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
xtifr@debian.org | microscopicsilico- to fit into a single
or xtifr@speakeasy.net | volcaniconi- standalone haiku
Reply to: