Re: Fixing Bugs

[EMAIL PROTECTED] (Jonathan Wakely) wrote on 16.06.05 in <[EMAIL PROTECTED]>: > On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote: > > > Aaron W. LaFramboise wrote: > > > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > > > the "Bicycle shed effect." > > >

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote: > Aaron W. LaFramboise wrote: >> > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this >> > the "Bicycle shed effect." >> > >> >

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Thu, 2005-06-16 at 10:30 -0400, Scott Robert Ladd wrote: > Aaron W. LaFramboise wrote: > > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > > the "Bicycle shed effect." > > > > > > If I'

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote: > Aaron W. LaFramboise wrote: > > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > > the "Bicycle shed effect." > > > > >

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Aaron W. LaFramboise wrote: > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > the "Bicycle shed effect." > > If I'm building a bicycle shed, I may want to talk with others who have done so

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

James A. Morrison wrote: Robert Dewar <[EMAIL PROTECTED]> writes: Yes, it's still the rule :-) and we have about 10,000 test directories now, many with a lot of code (it's many millions of lines in all, a good thing that machines are getting faster). In fact our test suite seems to take somewh

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar <[EMAIL PROTECTED]> writes: > Yes, it's still the rule :-) and we have about 10,000 test directories > now, many with a lot of code (it's many millions of lines in all, a > good thing that machines are getting faster). In fact our test suite > seems to take somewhat over an hour to e

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

chris jefferson wrote: > Working code is also of course by far the most convincing argument > :). Boosters, FreeBSD hackers, and I'm sure tons of others are calling this the "Bicycle shed effect." I agree. Prel

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Dave Korn wrote: > Perhaps I've missed something here, because I'm mystified how you could > think that gcc development is conducted by an organisation with full-time > staff. Perhaps not a formal staff, but there is a core group of developers whose incomes are closely tied to GCC development. M

RE: Fixing Bugs (Was: A Suggestion for Release Testing)

Original Message >From: Scott Robert Ladd >Sent: 14 June 2005 15:51 > In many ways, I see GCC as similar in model to the Red Cross. You have a > paid staff that handles the day-to-day business, Really? "GCC" has "paid staff"? Who are they? How much does "GCC" pay them? Where's the

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Laurent GUERBY wrote: At AdaCore (I assume it's still the rule), a patch was allowed to be committed only *after* a special run of the regression tester with CVS source baseline + only your patch showed a clean run (it was all automated so you just had to provide a clean patch to the system).

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: No, what they do is redefine the bug such that it is no longer a bug. Certain U.S. Presidents are quite fond of this tactic, recategorizing things to avoid dealing with them. Bug 323 is an example of how GCC does this. I don't know of any example of this. That is a cas

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: Testing and bug reporting are ways people can contribute to GCC if they haven't the time or knowledge to effect repairs themselves. Sure GCC isn't special; all areas of specialized knowledge have steep learning curves, and I'm certain I could find applications that w

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:43 PM, Timothy J. Wood wrote: On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote: I think a lot of what happens is that easy bugs do get fixed. The ones that don't are often complex, or ill-reported, and thus tend to require a lot of knowledge to work on effectively.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote: I think a lot of what happens is that easy bugs do get fixed. The ones that don't are often complex, or ill-reported, and thus tend to require a lot of knowledge to work on effectively. One form of mentoring would be to _not_ have the core

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Also, it seems you have the wrong belief that, if bug 323 were confirmed in | Bugzilla, a patch would automatically appear. I think the two events are | totally unrelated, especially for an issue which has been debated so much in | the past years, and

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Giovanni Bajo wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > First of all, I would consider polite to CC: me on the mail if you quote and > debate my statements. I meant no offense, and thought that I *had* CC'd you on the message. >>The ISO Standard doesn't prevent GCC from being *bette

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323, > which was a matter of recent discussion on this list. Some rather > respectable people (e.g., Vincent Lefèvre) consider this a bug, and > have proposed solutions. Yet here's a quo

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> I would like to improve floating-point in GCC; doing so scratches my >> personal itch. My silly idea is to determine the best approach >> *through discussion*. > Perfectly appropriate, and you are getting lots of discussion! And I'm burbling with

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: I would like to improve floating-point in GCC; doing so scratches my personal itch. My silly idea is to determine the best approach *through discussion*. Perfectly appropriate, and you are getting lots of discussion!

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, 2005-06-14 at 09:01 -0700, Mark Mitchell wrote: > CodeSourcery struggles with exactly the same problem; we have worked > hard to set up some test automation for our ARM builds, and it's working > well, but we're not (yet!) as disciplined as we want to be about > analyzing and fixing the

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

chris jefferson wrote: > One thing I have come across, both in gcc and in other projects, is that > often discussion is not the best option, but instead just writing some > code is better. There's a fine line between too much talk and not enough. > It's very easy to have discussions go around in

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: Richard Guenther wrote: Take a break and come back with results of actual work done, this impresses people a lot more than (repeated) ranting about gcc development in general. I have worked on GCC; not much, and probably trivial in your eyes, but practical wor

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Richard Guenther wrote: > Take a break and come back with results of actual work done, > this impresses people a lot more than (repeated) ranting about > gcc development in general. I have worked on GCC; not much, and probably trivial in your eyes, but practical work nonetheless. To trivialize con

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On 6/14/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > I wish I could do more, which is why I made (what I hoped were) > constructive suggestions for trying to get more people involved in > fixing bugs. For getting more people involved in fixing bugs they need those bugs

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

; and bug reports, someone has to fix the bugs before the users see benefit. I wish I could do more, which is why I made (what I hoped were) constructive suggestions for trying to get more people involved in fixing bugs. True, there are many lazy people who don't want to learn anything.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, Jun 14, 2005 at 09:01:04AM -0700, Mark Mitchell wrote: > Once I get my automated GCC bug-fixing bot finished I am going to have > an easy life. Unfortunately, I use GCC to build the bot, and I'm > getting an ICE in reload... > I have a patch for that. I'm sure the napking I wrote it o

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: That is exactly my point. Mark chastises people for talking about testing, implying that we are lazy for not providing patches. I don't deny that reality. Mark seems to feel that fixing bugs is as easy as testing and bug reporting, and it is not. Actually, I

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

> reasonably comprehensive training (i.e. at least a familiarity with > compilers > at the dragon book level, and reading some of the crucial papers > in the > area). I don't deny that reality. Mark seems to feel that fixing bugs is as easy as testing and bug reporting, and

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as >> well. I'm not saying that expectation is wrong, I am saying it is an >> impediment to working on GCC. > > with respect, I disagree, and I think you should invest the effort

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Scott Robert Ladd wrote: The ISO Standard doesn't prevent GCC from being *better* than specified, does it? Are we somehow breaking ISO compliance by doing math right? Is it so wrong to try and fix a problem that frustrates many people and makes GCC look bad? No, but you are degrading performan

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

ould invest the effort before you hazard an opinion here. Compilers are complex beasts, and all involve intermediate languages, and of course these intermediate languages must be learned before you can do anything. If there is a lack of people fixing bugs, don;t necessarily blame it on people being la

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, Jun 14, 2005 at 10:38:47AM -0400, Andrew Pinski wrote: > > On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote: > > >Andrew Pinski wrote: > >>This is wrong, there is an IRC channel which talks about technical > >>issues > >>deal with developing GCC (not with though but that should be i

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > FreeNode is not the only IRC server. irc.oftc.net is where #gcc is hosted. You are ebing positively rude. Just because I mention FreeNode doesn't mean I'm so ignorant as to be unaware of other servers. Where is irc.oftc.net #gcc above documented? ..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

on't see why you are complaining because code > generation bugs should be just reported and let the powers at be fix them. Didn't Mark just complain that people should spend more time fixing bugs than expecting others to do it for them? Mark complains that we already have too many unr

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Tue, 14 Jun 2005, Scott Robert Ladd wrote: > If I were to present a patch that implements the recomendations of the > Numerical C Extensions Group, would it be accepted or rejected (on the > subject alone; ignore for the moment potential technical bugs in the > submitted code)? I don't know to

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote: Andrew Pinski wrote: This is wrong, there is an IRC channel which talks about technical issues deal with developing GCC (not with though but that should be in an UNIX/C/C++ IRC channel instead). Where? A Google search on "GCC IRC" does

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > This is wrong, there is an IRC channel which talks about technical issues > deal with developing GCC (not with though but that should be in an > UNIX/C/C++ IRC channel instead). Where? A Google search on "GCC IRC" doesn't find much, and the few times I've visited #gcc on Fr

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: Gentoo provides a mentoring system for developers. This is far better than GCC's "fix it yourself and send us the code" policy. There is no gentle way to become involved in GCC; it's a sink-or-swim, trial by fire environment. If I could ge

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: Here's an example: Building new targets and fixing some code generation bugs involve changing the machine definitions, which are written in a rather uncommon language. Frankly, I haven't figured out all the nuances yet, mostly because I d

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote: For that matter, Gentoo also has some very excellent IRC channels that provide a lot of help, and usually *friendly* help at that. The GCC mailing lists are useful, but there's nowhere to go and have a quick chat about "this is confusing th

Fixing Bugs (Was: A Suggestion for Release Testing)

Mark Mitchell wrote: > I'm all for more testing -- but I have a standard rant about it being > easier to run tests than to fix problems. We actually have a wealth > of known regressions -- some pretty serious -- in Bugzilla, and > plenty more known bugs. Most come from real problems reported by