public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: Dara Hazeghi <dhazeghi@yahoo.com> Cc: jsm28@cam.ac.uk, Giovanni Bajo <giovannibajo@libero.it>, <gcc-bugs@gcc.gnu.org> Subject: Re: NEW vs. UNCONFIRMED Date: Sun, 01 Jun 2003 01:15:00 -0000 [thread overview] Message-ID: <Pine.LNX.4.44.0305312002550.10118-100000@gandalf.ices.utexas.edu> (raw) In-Reply-To: <486DCCCA-93CC-11D7-A14F-000393681B36@yahoo.com> > I guess I agree with you in principle, I just feel you standards are a > bit too stringent. Especially for runtime bugs, I'm not certain whether > it's necessarily fair to ask the submitter to try multiple compiler > versions, particularly if the failing one is the current release. I think I left out something: I wouldn't have closed the report if I didn't get feedback, or if it wasn't sufficient. I would just have left the PR open. We're presently having a problem with PRs in WAITING: you guys have been putting lots of PRs into WAITING, for which I have the feeling that there's already enough info in the PR. We shouldn't be closing these reports if we don't get feedback in 3 months. We should review each of them again then. > > You should alse make sure that the bug report seems to contain sufficient > > information for anyone with the right platform to reproduce it (all > > required sources, compiler options, what is considered to be wrong, ...). > > Given that information is present, and that what is described as being > > wrong does indeed look like a bug, I think treating the bug as confirmed on the given > > version and platform is reasonable. That sound reasonable for bugs on obscure targets. > I think something along these lines will provide the necessary > information, without asking too much of the reporter... Especially > since for other types bugs, we tend to have a somewhat lower threshold. For example? For C/C++/Optimization, we do not put PRs into NEW just because it "looks like this could indeed happen". I would be very much opposed if we would adopt this as sufficient. > Perhaps then we should set up a list of platforms, Basically: Wolfgang x86-linux only Volker same Christian sparc Giovanni windows stuff Falk alpha (and some more) Dara seems like everything else :-) > and people who are > willing to test code on them? As it is, usually I just end up asking > whoever seems most likely to have such systems, but I'd be reasonably > confident that among all the "bugs people" and the regular developers > we cover most of the platforms. Thoughts? Well, MAINTAINERS lists who's responsible for a platform. If we can't find someone with a platform, this would be the person to ask. Except, that this doesn't seem to work most of the time -- responsible seems to be a more flexible word than I thought. > Another question I have is about including the platform of a bug in the > summary (ie "[powerpc64] blah fails doing foo". Now that Daniel has > made it possible to edit the host and target fields (thanks again!), it > seems to me that we should be using those, rather than the bug summary, I'm not yet won over -- PR submitters will fill in these fields for front end bugs as well, and then searching will become more difficult again. Also, what if a bug exists on multiple targets? > Finally, a question about maintainers and bugs. Is there a consensus as > to when it is okay to assign a bug to someone, and when it is okay to > add someone (who's responsible for the relevant portion of the > compiler) to the cc: list of a bug? Thanks, I do it with a few people who I know are usually responsive to my requests. Otherwise only if I contacted them on- or off-list. I consider it as impolite just assigning a bug to someone without asking beforehand. I think this is a question for the maintainers to answer. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
next parent reply other threads:[~2003-06-01 1:15 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <486DCCCA-93CC-11D7-A14F-000393681B36@yahoo.com> 2003-06-01 1:15 ` Wolfgang Bangerth [this message] 2003-06-01 1:32 ` Andrew Pinski 2003-06-01 1:38 ` Wolfgang Bangerth 2003-06-01 3:56 ` Tim Prince 2003-06-01 4:25 Dara Hazeghi -- strict thread matches above, loose matches on Subject: below -- 2003-06-01 4:21 Dara Hazeghi 2003-06-02 15:53 ` Wolfgang Bangerth 2003-06-01 1:01 Dara Hazeghi 2003-06-02 7:32 ` Ben Elliston
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44.0305312002550.10118-100000@gandalf.ices.utexas.edu \ --to=bangerth@ices.utexas.edu \ --cc=dhazeghi@yahoo.com \ --cc=gcc-bugs@gcc.gnu.org \ --cc=giovannibajo@libero.it \ --cc=jsm28@cam.ac.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).