Re: BTS: Why no "invalid" or "notabug" tag?
Russ Allbery <rra@debian.org> writes:
> Manoj Srivastava <srivasta@debian.org> writes:
>
> > Out of curiousity, what _did_ you expect the blocking tag to do?
> > If there is an obvious answer to that, I can see why not having
> > that behaviour would be a surprise.
>
> The one thing that I really wanted to have happen and was surprised
> didn't happen was that I wanted a blocking annotation be
> automatically removed when the blocking bug was closed. (Or even
> better, made dormant so that if the other bug would reopen, the
> annotation would reappear.)
I would find this more sensible:
- Ben Finney asks BTS to mark bug 123 as blocking bug 789.
- BTS updates bug 123 and bug 789 correspondingly
- Russ Allberry asks the BTS to mark bug 789 as resolved.
- BTS rejects the change, saying that bug 789 can't be resolved
until bug 123 is resolved
- Russ Allberry sees in the bug list that bug 789 is blocked.
- Russ Allberry asks Ben Finney what to do about the block.
- Ben Finney gives a patch to Manoj Srivastava to fix bug 123.
- Manoj Srivastava asks BTS to close bug 123.
- BTS updates bug 123 and 789 correspondingly
- Russ Allberry sees in the bug list that bug 789 is not blocked.
- Russ Allberry asks the BTS to mark bug 789 as resolved.
- BTS updates bug 789
In other words, the block affects the possible work flows for the bugs
involved -- if bug 789 is blocked by 123, that's an indicator that bug
789 can't be resolved until the block is cleared, so the BTS should
enforce that.
The data about the block reflects something the real-world developers
should know about the bug, and when that real-world information
changes, the bug record need to be updated to reflect that.
--
\ "The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything." -- Aahz |
_o__) |
Ben Finney
Reply to: