From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14236 invoked by alias); 8 Jan 2004 00:30:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14227 invoked from network); 8 Jan 2004 00:30:22 -0000 Received: from unknown (HELO smtp6.mindspring.com) (207.69.200.110) by sources.redhat.com with SMTP; 8 Jan 2004 00:30:22 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AeO41-0006Bi-00; Wed, 07 Jan 2004 19:30:17 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id B7A674B35A; Wed, 7 Jan 2004 19:30:47 -0500 (EST) To: cagney@gnu.org, gdb@sources.redhat.com Subject: Re: GDB 6.1 branch end jan? Message-Id: <20040108003047.B7A674B35A@berman.michael-chastain.com> Date: Thu, 08 Jan 2004 00:30:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00076.txt.bz2 Andrew C writes: ~branch 2004-01-31 ~release 2004-03-15 I'm comfortable with 6 weeks for branch-to-release. I think 2004-01-31 is okay, depending on whether people spend time fixing high-priority bugs or not. If they don't fix the bugs before the branch then we will have to fix them on both branch and HEAD and that's just more work. If we have known bugs, and you decide we have to fix them, then I'd rather branch later and release earlier. bugs with priority=high (4): http://sources.redhat.com/gdb/bugs/1417 crash when printing variables http://sources.redhat.com/gdb/bugs/1405 regression: print pEe->vf(), virtual baseclass both, g++ 2.95.3 -gdwarf-2 http://sources.redhat.com/gdb/bugs/1398 Path handling bug which makes GDB unable to stop at breakpoints http://sources.redhat.com/gdb/bugs/378 ``GNU/Linux" ``Linux kernel" bugs with severity=critical marked "regression" (1): http://sources.redhat.com/gdb/bugs/1501 [regression] src-release broken, uses obsolete sun4 configuration There are 47 total severity=critical bugs. This bug deserves high priority: http://sources.redhat.com/gdb/bugs/1470 ELF_LINK_POINTER_EQUALITY_NEEDED breaks shlib-call.exp binutils HEAD has a new PLT optimization which gdb does not handle. I say it's a problem in binutils but Jakub J says it's a problem in gdb. Coverage with gcc HEAD -gstabs+ has not been available since the ABI upgrade. (That's why I haven't published a report since before the ABI change. I have to fix some more gdb.cp/*.exp files, and I've been waiting a week for any more fallout from my last rewrite). I'd like to have some more visibility from this before branch. If I've been doing the sunday project perfectly, then every test result regression from gdb 6.0 has already turned into a priority=high bug with "regression" in the name. But I may have missed something. So there might be about 1 more bug in there when I examine the "compare by gdb" tables. I estimate 0.1 to 0.3 bugs. :) hppa*-hp-hpux* support is better than 6.0 (it would be hard to be worse than "does not build"), but it's probably worse than the last good gdb version, whatever that was. It passes the "break main" test, at least when gdb itself is built with gcc. Michael C