Re: Closing bugs in unreleased packages?
On Sat, Mar 15, 2003 at 11:06:03AM -0700, Bob Proulx wrote:
> The released version of Debian is 'stable. Why are bug reports closed
> against 'sid'? Shouldn't bug reports be closed only in released
> versions of Debian? What am I missing? Requesting education.
Because we don't yet have proper version tracking in the BTS, and it's
quite a difficult problem to solve correctly: several of us have been
pondering the problem for a while.
> This documentation leads one to believe that if they see a bug in
> 'stable' that they should report it, no?
Yes, although in an ideal world you would make some attempt to check
against unstable too if possible. Bug numbers are (relatively) cheap,
and reports already-fixed problems don't do much harm other than maybe a
slight rise in blood pressure depending on how bad a day the
maintainer's had so far.
> A package maintainer who is following the rules, will fix the bug,
> update the package in sid, close the bug. The bug, now closed will
> disappear from the BTS (being moved to the archive of closed bugs,
> requiring archive=yes to view). Users using released Debian 'stable'
> observing the bug who are following the rules will not see the closed
> report, will report the bug again. The maintainer will see the
> duplicate bug report and close it. Repeat. Repeat. Repeat. The
> time period during which this may continue could be the two years it
> took to release 'woody'.
Yup. Right now, the answer is "unlucky", sorry (the "tag it woody"
strategy doesn't really impress me much, because it's an ugly hack).
Hopefully we'll be able to improve this in time.
If something is *that* frequently reported, it's possible that it merits
an update to stable, too.
> The maintainer is frustrated by seeing the same bug reports for things
> they have fixed and are in the pipeline to stable but not there yet.
> Again and again. The user is frustrated because they are not seeing
> any of those bug reports. They are going through effort to create a
> good bug report, only to be told it is a duplicate. Then they are
> told to go away, and in some cases griped at for filing a duplicate
> bug.
Maintainers who gripe at people for that probably ought to be
"educated", although a lot of maintainers do have legitimate
duplicate-bug rant reflexes due to the number of people who report
duplicates of still-open bugs. (My personal rant is the phenomenal
number of people who reported duplicates of #165254.)
> Shouldn't bugs be "not-closed" until the package moves into 'stable'?
> (I did not say "open". After a fix perhaps "fixed", or "resolved" to
> show that it has been addressed in a package that has not yet made it
> to 'stable'?)
What should happen is that the bug tracking system should record the
versions in which a bug was reported and in which it was closed, and
have different open-bug views for different distributions, the default
being unstable. Recording these details is pretty easy (many people seem
to assume that's the hard part for some reason), but the difficult and
unsolved bit is working out how to tell how the versions correspond to
distributions. For example, say 1.0-1 is in stable and 1.1-1 is in
unstable, then 1.0-2 is uploaded to stable to fix a security
vulnerability and 1.1-2 is later uploaded to unstable. Obviously we
can't just assume that 1.1-1 fixes all the bugs in versions that compare
less than it: we need to know what the version tree looks like for all
distributions. Since the bug tracking system runs on a different machine
from the master archive this isn't an entirely trivial exercise, and in
particular it turns out not to be as simple as just grabbing up-to-date
Packages files every day.
This is probably the highest-priority issue facing debbugs right now,
although also probably the most difficult.
See the archives of debian-debbugs for (a little) more discussion on
this subject.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: