[arch-dev-public] Upstream bug closures
paul at mattal.com
Tue Nov 10 07:28:26 EST 2009
James Rayner wrote:
>> Jan de Groot wrote:
>>> I see a lot of bugs getting closed with "Upstream" lately because
>>> they're not packaging bugs. This is not the way to solve bugs. The only
>>> bugs that should be closed upstream are the ones in binary modules like
>>> flashplugin or nvidia binary drivers. Opensource software can be fixed
>>> or debugged, so we should do that instead of using this bogus closure
>> I agree if a package is actually broken then the bug report should
>> remain open with a link to the upstream bug report so that a patch can
>> be pulled when this is fixed upstream.
> Just an example of when to not close something as upstream. I have a bug
> assigned to me, with a patch available, for a project that isn't very
> actively maintained. Someone closed the bug as 'upstream'. This, doesn't
> really work well, because new releases are unlikely/uncommon, and a patch
> is available.
> The other case where closing bugs as upstream is bad, is when the bug is
> not upstream. I have at least once had a packaging error closed as
> If anyone is to close a bug as upstream, I suggest it should be the
> maintainer of the package as they are most likely to appreciate the
> situation best. A broad policy on upstream packages is unlikely to work
> due to the variations in each case - rather maintainer intuition is best.
Here's my take on this one: It's a special case for which we already
have a solution-- for the maintainer to reopen the bug. Assignees get
email when a bug is closed, and it's trivial to return to that page and
reopen the bug. Certainly if the maintainer reopens the bug, nobody
should then then close it as upstream against his/her wishes.
In the meanwhile, our developer and community effort is not spread thin
looking at bugs that perhaps should be closed, while other go untouched.
There's a real cost to leaving a bug open-- someone(s) somewhere will
spend time looking at it rather than applying their effort where it
would be better spent; if we just harnessed that effort alone, we'd have
many fewer bugs.
More information about the arch-dev-public