From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,751d508677a5add1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: Reporting bugs in GNAT (was: [Ada] made me hate programming) Date: Tue, 24 Aug 2010 13:32:55 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <8f469661-370c-4484-82d8-f1b365455e0f@w12g2000yqj.googlegroups.com> <98aa58b3-50fc-418d-9f72-524b5a23c89d@t10g2000yqg.googlegroups.com> <87hbilt6ua.fsf_-_@ludovic-brenta.org> Injection-Date: Tue, 24 Aug 2010 13:32:55 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="15606"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+00y1f7YTFyy6c+17qnuTTO4AQOEtEIrQ=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:DqseHC191rBR5UUTB7OexDr88uo= Xref: g2news1.google.com comp.lang.ada:13699 Date: 2010-08-24T13:32:55+00:00 List-Id: Ludovic Brenta expounded in news:87hbilt6ua.fsf_-_@ludovic-brenta.org: > Warren writes on comp.lang.ada: >> It can be a fun exercise to see what is provoking the bug box. While >> it is best to report those, I do find that the present reporting >> "process" is too time consuming. I find it is quicker and eaiser to >> find a work-around and hope that the bug has already been reported. > > While I understand your point of view, your attitude is exactly the one > that ensures your bug cannot possibly be fixed, ever. I understand your point also, but this statement of yours is not absolutely true: In a recent case, I did not "locate" my bug. After wasting 3 hrs to submit it, it was closed with "already known" or some such. Presumably there are other unsubmitted bugs in the same category. ;-) >> Only as a last resort, I'll report it. > > OK but that's another mistake. If reporting a bug is your last line of > defense, this means you're pretty much cornered and have become > dependent on someone else understanding your problem, implementing > a fix > and delivering the fix to you. No, no, no, no. I find me a work-around. If I can't, I _will_ make the effort (or when the work-around is ugly). If I think the problem is one that really needs to be fixed (for the greater good), then I _will_ take the time. But it's a judgement call, and I haven't encountered many in that category, thankfully. > I suggest that if you invest a couple of hours of your precious hobby > time on just *one* compiler bug to properly isolate it in a reproducer, > you will not only gain a lot of insight into the process but you will > also deserve, and obtain, a lot of goodwill from the GCC maintainers > (not only those at AdaCore, but also enlightened enthusiasts like Sam > Tardieu and Laurent Guerby, to name but two). This might lead to a fix > sooner than you think. I think the reality of the situation is that they already get a boat load of problem reports. Since the supply is plentiful, they don't have to be concerned with how easy the input process is. That's the bottom line. I am contributing to open source in my own way (I have several projects up on SF for example). I started the APQ project, which I see is still used. If I have to trade all or most of my free time to contribute to gcc, then I might as well give up my projects and join the gcc team (by then I'd rather pick up a guitar). In these kinds of things consequently, there are judgement calls involved. No one answer fits all. >> Instead they insist on *ada files and don't want anything that is not >> involved. Gnat tries to name the involved sources, but I have found >> that this isn't reliable - resulting in more futzing around. > > That's a small issue with file naming. Once you've done it once, you > can do it again quite easily. It's not just that, but deciding which of hundreds of sources to send etc. It's the "list" of their requirements before they will even look at it. If the list was shorter, the process would be easier. I tell ya what- if I decide to submit a new bug at some point, I'll invest the time to automate much of that. Apart from eliminating non- participatory source modules one by one and describing the problem, I suspect much of it can with a bit of effort be scripted. But that will have to wait for a rainy day. Warren