public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/8931: g++ 3.2 fails to enforce access rules Date: Fri, 13 Dec 2002 13:26:00 -0000 [thread overview] Message-ID: <20021213212601.31484.qmail@sources.redhat.com> (raw) The following reply was made to PR c++/8931; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: Gabriel Dos Reis <gdr@integrable-solutions.net> Cc: gcc@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>, <sebor@roguewave.com>, <gcc-gnats@gcc.gnu.org> Subject: Re: c++/8931: g++ 3.2 fails to enforce access rules Date: Fri, 13 Dec 2002 15:17:17 -0600 (CST) > | Synopsis: g++ 3.2 fails to enforce access rules > | State-Changed-From-To: open->closed > | Since it is not a regression, it is not going to be fixed > | in any 3.2.* and there is no value in keeping this report > | open. > > It would be really helpful if non-invasive bug fixes could make it to > branch when it is not frozen. > > Setting the bar to only regression fixes is, IMHO, too high and > renders the dot releases less useful and less attractive. Indeed, > I've seen lot of PRs being closed on the basis that they are fixed on > mainline and since they are not regressions they won't be fixed in > 3.2.x. The net effect is that people would have to wait for some (long) > undeterminated time before they had a compiler that fixes the bugs, > and meanwhile we will be releasing compilers that could include > those patches. I think I even concur, I am just executing the policies that have been set. However, in the discussion I would like some points to be kept in mind: - if there are too many open reports in the database, it is difficult to manage and very annoying when one re-visits reports that are "half-open" every so often. You do realize that we presently have about 1800 (!) non-closed reports and that it is easy to lose yourself into this amount, right? - given the really *large* number of open bug reports, I think the scarce bug fixing resources gcc has serve the community better in the long term if we let them focus on 3.3, rather than spending time backporting fixes. This way we might get 3.3 out earlier, which will certainly be better than any 3.2.2. - if we allow other patches into the branch, it needs more testing; the thing with limited resources applies here as well. - someone will have to find the patch that fixed it on the mainline. For this particular case I don't know how invasive the fix might be, so I can't comment on its impact on stability of the branch. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
next reply other threads:[~2002-12-13 21:26 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-12-13 13:26 Wolfgang Bangerth [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-12-13 13:46 Gabriel Dos Reis 2002-12-13 13:16 Gabriel Dos Reis 2002-12-13 12:49 bangerth 2002-12-13 12:16 sebor
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=20021213212601.31484.qmail@sources.redhat.com \ --to=bangerth@ticam.utexas.edu \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /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).