Am Sat, 14 Apr 2012 11:42:16 +0200 schrieb Jan de Groot :

Recently I've seen several bugs getting closed as "upstream". This is not just about bugs in nvidia drivers or bugs in flashplayer, but also about bugs in the intel drivers that upstream has patches for. Closing this means that we still suffer from that bug until upstream releases a new driver 3 months later. This is totally unacceptable for me.

So, as for "upstream": only close bugs that we can't fix locally. This includes closed software, but also bugreports about design choices done upstream (for example: the nodisplay=true entry in evince.desktop). Closing valid bugs as "upstream" renders our bugtracker useless, as we'll get new bugs reported for the same bugs in a later stage, or people request re-open anyways because it's still not working.

Most devs seem to have an opposite attitude. http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February/022531.... When we say we ship vanilla stuff it's valid to close with "upstream" and leave post release fixes up to the users. If we see it our task to fix true bugs we can apply patch everything. That's a question of "Arch way". -Andy

Am Sat, 14 Apr 2012 12:28:36 +0200 schrieb Jan de Groot :

On za, 2012-04-14 at 11:53 +0200, Andreas Radke wrote:

...

When we say we ship vanilla stuff it's valid to close with "upstream" and leave post release fixes up to the users.

If we see it our task to fix true bugs we can apply patch everything.

That's a question of "Arch way".

So the Arch Way is to package broken software and close any bug you receive as upstream?

If a bug doesn't affect all users I tend to say yes. We ship what is working for most users. When a workaround is known (e.g. pkg downgrade, some config file option...) we can close the bug as upstream or apply a fix that will work for all users. If no fix is available I don't see the need to keep a copy of an upstream report open for all time. I'm fine with leaving bugs open until upstream has received all needed information (usually upstream bug reports) and then close our bug. We could define a rule all devs should follow to define what the "Arch way" means. A simple sometimes broken toolkit to leave it up to the users or work much harder and ship a best working out of the box distro. Our men power is limited and our current way seems to work pretty well for years now depending how much time the pkg maintainer has and how good he knows the pkg and upstream development. Can't we keep it that way? -Andy