On Sun, 6 May 2001, Chris Waters wrote: > > > Didn't we already have this discussion? The Standards-Version field > > > is not a reliable indication of much of anything. I strongly object > > > Policy says: > > "Policy says" doesn't make the packages comply. And you can file all > the bugs reports you want, but that doesn't magically fix the > packages. And until they're fixed, you can't use them as a reliable > indicator of FHS compatibility. QED.
Standards-Version < 3 : a not FHS compliant package is at most a "normal" bug Standards-Version >= 3: a not FHS compliant package is at most a "serious" bug > We have many packages with old Standards-Versions which actually > comply with newer standards and *are* FHS compatible, and we have > packages with newer Standards-Versions that are NOT FHS compatible. Please file RC bug on packages with Standards-Version >= 3 that are not FHS compatible. > I think that if you really want to focus on FHS compatibility, you're > better off ignoring the Standards-Version issues for now. Its just > another can of worms. Picking the minimum Standards-Version for > release is something we normally do at freeze time. I think it's important that our packages follow a not too outdated policy and the "Standards-Version" field is the indicator for this. Freeze time is too late for picking the minimum Standards-Version for release - the right time would be shortly after the last stable was released. An example: It would be nice to have a minimum Standards-Version of 3.1 (that includes build dependencies), but you can't file 1060 RC bugs at the beginning of a freeze. >... > 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 . > > > to removing packages because of what amount to cosmetic issues, and an > > > Where did I say that I want to remove the packages??? > > I said that I want to send bug reports. > > RC bugs mean the package must be removed from the next release if it's > not fixed. Unless you can guarantee that the bugs will be fixed > (i.e., you're volunteering to fix them yourself), you _are_ asking for > package to be removed when you file RC bugs. These bugs are relatively easy to fix bugs and many of them will be fixed at a bug squashing party - and yes, I do fix many "easy to fix bugs" at each bug squashing party. But BTW: When a maintainer doesn't even when there's a RC bug starts to work on upgrading the package to comply with a policy that is nearly two years old there's the question of he's MIA. > Anyway, I apologize for a reminder I'm sure you don't need. It's just > a habit of mine, please forgive me. > > 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... >... > And I think mass filings of RC bugs would be premature at best. It's perhaps really late because we are relatively close too a freeze but it's definitely not premature. > cheers cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.