FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 04-14-2012, 09:42 AM
Jan de Groot
 
Default "Upstream" bug closure

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.
 
Old 04-14-2012, 09:53 AM
Andreas Radke
 
Default "Upstream" bug closure

Am Sat, 14 Apr 2012 11:42:16 +0200
schrieb Jan de Groot <jan@jgc.homeip.net>:

> 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.html



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
 
Old 04-14-2012, 10:28 AM
Jan de Groot
 
Default "Upstream" bug closure

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?
 
Old 04-14-2012, 11:52 AM
Andreas Radke
 
Default "Upstream" bug closure

Am Sat, 14 Apr 2012 12:28:36 +0200
schrieb Jan de Groot <jan@jgc.homeip.net>:

> 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
 
Old 04-14-2012, 11:58 AM
Pierre Schmitz
 
Default "Upstream" bug closure

Am 14.04.2012 13:52, schrieb Andreas Radke:
> Am Sat, 14 Apr 2012 12:28:36 +0200
> schrieb Jan de Groot <jan@jgc.homeip.net>:
>> 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.

It'll be hard to find a general rule here. It depends on how critical a
bug is, if a patch is approved by upstream and how trivial a patch is.
I'd also say that it is only useful to clsoe a bug if there was at least
minimal communication. E.g. closing as upstream is not useful if
upstream does not know about the problem. So at least tell the user to
report upstream and once they took over you may close the bug on our
side.

--
Pierre Schmitz, https://pierre-schmitz.com
 

Thread Tools




All times are GMT. The time now is 03:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org