Gentoo Archives: gentoo-amd64

From: Frank Peters <frank.peters@×××××××.net>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: Digest of gentoo-amd64@lists.gentoo.org issue 367 (13009-13035)
Date: Sat, 09 Jul 2011 06:03:37
Message-Id: 20110708195622.981b7eef.frank.peters@comcast.net
In Reply to: [gentoo-amd64] Re: Digest of gentoo-amd64@lists.gentoo.org issue 367 (13009-13035) by DJ Cozatt
On Fri, 08 Jul 2011 16:46:38 -0400
DJ Cozatt <ygdrasil@×××××××.net> wrote:

> > Is a discussion/flame about the report upstream qa messages. > Help me out here guys and weigh in. (dons flame suit) >
To be honest, I am still quite surprised at the fact that distribution maintainers even waste time fixing obvious bugs, let alone QA issues. If anything, outright bugs should be the responsibility of the upstream developers and only of the upstream developers. Yet there seems to be this many-tiered approach to reporting and fixing bugs, with each distribution maintaining its own independent set of reports and patches. This makes little sense. For example, there are patches available on Gentoo (and other distributions as well) that are needed to fix certain software bugs but these same patches are not included in the original source code. The way I see it, there is much manpower being wasted by having all of this duplicated effort. Upstream developers should be very accommodating when it comes to bug reports. After all, the software is *their* creation and their sense of pride -- if nothing else -- should impel them to release the best possible code. But upstream developers are known to sometimes be less than enthusiastic about bugs. I experienced an issue recently with the login program and thought it best to make a report to upstream only (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600755). After a long period with no significant response I decided to file a report with Gentoo ( https://bugs.gentoo.org/show_bug.cgi?id=324419). The Gentoo developers tackled the problem and found the source of the error. I reported these results back to upstream where hopefully the bug will be fixed, but there should not have been the need to approach both parties. As far as QA issues, this should definitely be only the concern of upstream developers. The only way to improve code for every user is to put pressure, in the form of constructive criticism, on upstream to adhere to good coding practice.
> Further on the conversations wandered-to in the topic 'optimization' > in the kernel config menu under the heading 'General Setup' lies > [*] Optimize trace point call sites >
Is This option for debugging purposes? If so then there is no need for it with ordinary user builds. Frank Peters