Re: Debian doesn't have to be slower than time.
> > ... Don't try to please everybody. Is a given RC bug really
> > release-critical or is it more of a "release-should" or perhaps even
> > a "release-wish"? If so, then forget it and move on this time. Let
> > it get fixed in the next release. This only works, though, if you're
> > doing releases every 6 months or less.
>
> In this case, shouldn't the severity of the bug be reduced to a more
> appropriate level? After all, release-_critical_ should mean just that:
> critical. Shouldn't it?
Yes. The definitions of the different severities are tough to manage.
As I recall, "critical" means the package compromises other packages,
"serious" means the package has security holes or is largely non-functional,
and "important" simply meant that it was something that needed to be
fixed before release ("better left out that in with this bug").
Unfortunately, this isn't really a good measure. For example, should
"xload" be omitted because it has a /tmp race condition. Assuming the
race condition is difficult to exploit, why is it worth removing? True,
it meets the "serious" criteria in theory, but practice my be something
else. (Note that this is a purely fictional bug.)
No release we ever do is going to be perfect. You can release with
serious bugs and then do point-releases every month to correct these
things over time. They _should_ be fixed -- I don't think anybody would
argue against that; the point is "do they have to be fixed _now_?".
I would bet that there are _more_ security bugs out there today than
there would be if Debian shipped last month with all of the bugs
known at the time. Why? Because many people won't do incremental
"security" updates. They'll only do major upgrade.
I'll give you a real example: Every week, the three internet-connected
computers I manage receive between 2 and 5 SSH-1 "compensation dectector"
attacks every week... EACH! That means that there are a lot of old
systems out there that are still running un-patched ssh1 daemons. These
computers were obviously not updated with any kind of security point-
releases.
Granted, a new major release may not get them upgraded either, but my
point is that you're not gaining yourself anything by waiting.
> If the bug is not that critical, then perhaps it should be marked as
> "important" or "normal". (Normal bugs should be fixed too.)
> Furthermore, if the release managers downgrade the severity of the
> report with an explanation as to why it does not merit attention for the
> current release, then there is a record of their decision. Everyone can
> see that the bug was not fixed for the current release on purpose, and
> was not just an oversight.
When I was "release managed", I'd do that every week or so. That cleaned
up about a third of them. Of course, some people complained and bumped
them back up, but at least the maintainers knew I would support them if
they also felt it wasn't that serious.
Everybody who reports a bug would like to see it fixed before the next
release. If it didn't affect me, I wouldn't be reporting it in the first
place. People just need to realize that getting the software out there
is more important than getting it right because if it never ships, then
who cares how few bugs it has?
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Illigitemus non tattus carborundum! (Don't let the bastards grind you down.)
Reply to: