[arch-dev-public] Upstream bug closures
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 option.
On 09/11/2009, Jan de Groot <jan@jgc.homeip.net> 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 option. I agree with you here. We should debug or fix software issues (I closed 30 minutes ago an upstream bug about sonata, but I will investigate on that), anyway the recent closed bugs are about kernel and some devices and I do not know how many of us are kernel developers.
-- Andrea `bash` Scarpino Arch Linux Developer
Am Mon, 9 Nov 2009 19:27:44 +0100 schrieb Andrea Scarpino <andrea@archlinux.org>:
On 09/11/2009, Jan de Groot <jan@jgc.homeip.net> 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 option. I agree with you here. We should debug or fix software issues (I closed 30 minutes ago an upstream bug about sonata, but I will investigate on that), anyway the recent closed bugs are about kernel and some devices and I do not know how many of us are kernel developers.
A can't completely agree on that. While it is ok to keep such a bug open the debugging and fixing should be done in the upstream bugtracker not in our one. Our users too often expect the packager (or the one who helped out) to solve configuration problems, debug code and fix the bug or do the upstream communication. I can't do this and don't want to do this for all my packages. It's already hard enough to follow all the mailing lists to see major changes and where our packaging is affected. I'm not interested to do upstream work where I don't want to. I'm just a packager for Arch Linux. -Andy
Andreas Radke wrote:
Am Mon, 9 Nov 2009 19:27:44 +0100 schrieb Andrea Scarpino <andrea@archlinux.org>:
On 09/11/2009, Jan de Groot <jan@jgc.homeip.net> 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 option. I agree with you here. We should debug or fix software issues (I closed 30 minutes ago an upstream bug about sonata, but I will investigate on that), anyway the recent closed bugs are about kernel and some devices and I do not know how many of us are kernel developers.
A can't completely agree on that. While it is ok to keep such a bug open the debugging and fixing should be done in the upstream bugtracker not in our one.
Our users too often expect the packager (or the one who helped out) to solve configuration problems, debug code and fix the bug or do the upstream communication. I can't do this and don't want to do this for all my packages. It's already hard enough to follow all the mailing lists to see major changes and where our packaging is affected.
I'm not interested to do upstream work where I don't want to. I'm just a packager for Arch Linux.
I second Andy's opinion. It's not that I don't want to fix bugs upstream, I just disagree that our bugtracker is a place to track them. That said, I think it's reasonable for us to try to *report* them upstream even if they aren't *fixed* by us. Perhaps we should agree to: 1) Make sure the bug is reported upstream first and, 2) Put a URL in a comment or the closing message pointing to that bug report upstream before closing with 'Upstream'. - P
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 option.
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. But I have used "upstream" to close bugs that I will not leave hanging around in the bug tracker because they are very minor issues that I know upstream do not care about (e.g. glibc first day of the week issues). If there is going to be no upstream patch, then we should not be patching ourselves. Allan
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 option.
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 upstream. 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. James
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 option. 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 upstream.
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. - P
participants (6)
-
Allan McRae
-
Andrea Scarpino
-
Andreas Radke
-
James Rayner
-
Jan de Groot
-
Paul Mattal