[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Reply to: