Re: Finishing the FHS transition
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.
Reply to: