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

Re: [debian-devel] Re: [debian-devel] Re: fixing debconf stdin bug



A levelezőm azt hiszi, hogy Andreas Metzler a következőeket írta:
> > Well, maybe I am kidding a bit, but I would like to see
> > extremely hard measures towards release time. See how they
> > have helped the kernel, and how Linus himself was surprised
> > that the developers behaved themselfes.
> 
> Maybe I am stating the obvious but your analogy is broken. Linus did
> not suddenly broaden his definition of an release-critical bug towards
> release time, therefore increasing the number of rc-bugs. Instead he
> decreased their number by cutting down the must-fix list and he
> rejected any patch that had any effects beside fixing an rc-bug.

My point was that hard measures needed, and I brought out Linus as an
example where hard measures did work, and did not came with the
amount of whining which was foreseen.

The point is that kicking of all packages with an RC bug definitely
lowers the number of RC bugs. I also say that any package which is
important will soon get back in an rc-bug-less state.

You are true that broadening the definition of RC bugs at this
time is not a good idea. This does not necessarily means that
I agree with you that this bug class is not RC.

I consider the point about hard measures more important than
the question of the stdin bugs, but let's see what I think of
the bugs:
-An uninstallable package is an RC bug.
-The question is whether the package itself or the installer
 which steals stdin is the cause of the bug.
-AFAIK the policy manual is clear on that one should use
 debconf or similar mechanism, and the user input should be
 on /dev/tty at the end of the chain.
-There might be a clause in the policy manual which says that
 stealing stdin is a bad thing. In this case you can argue that
 the installer is broken, and the bug RC there, not in the
 packages.
-Life is full of compromises. If it turns out that a lot
 of packages have the stdin bug, it is arguable that looking
 over the fact(? see the previous point) that they are
 RC bugs is temporarily okay, and working it around in the
 installer is a ... ehrm ... workaround we can live with
 temporarily. But even in this case we should know that an rc bug is
 an rc bug is an rc bug.

In short: I am not 100% sure that they are really RC bugs, but
now I tend to think so. And I am 100% sure that kicking off
packages with RC bugs is a Good Idea.

-- 
GNU GPL: csak tiszta forrásból



Reply to: