From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28975 invoked by alias); 5 Mar 2009 06:05:59 -0000 Received: (qmail 28966 invoked by uid 22791); 5 Mar 2009 06:05:58 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp03.br.ibm.com (HELO e24smtp03.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Mar 2009 06:05:49 +0000 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by e24smtp03.br.ibm.com (8.13.1/8.13.1) with ESMTP id n2562wE4003429 for ; Thu, 5 Mar 2009 03:02:58 -0300 Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n25759QN3862646 for ; Thu, 5 Mar 2009 04:05:09 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2565kM7000817 for ; Thu, 5 Mar 2009 03:05:46 -0300 Received: from [9.18.200.51] ([9.18.200.51]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2565cje000737; Thu, 5 Mar 2009 03:05:41 -0300 Subject: Re: google summer of code From: Thiago Jung Bauermann To: =?UTF-8?Q?O=C4=9Fuz?= Kayral Cc: gdb ml In-Reply-To: <36a35d480902270041g4c90775fl5634e04b7f41b2f@mail.gmail.com> References: <1235658320.5890.18.camel@localhost.localdomain> <36a35d480902270041g4c90775fl5634e04b7f41b2f@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Date: Thu, 05 Mar 2009 06:05:00 -0000 Message-Id: <1236233132.24825.24.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00052.txt.bz2 Hi Oğuz, El vie, 27-02-2009 a las 10:41 +0200, Oğuz Kayral escribió: > Hi, > The guys at Nmap preferred to apply for "Feature Creepers and Bug > Wranglers" positions in order to have some students to work on lots of > small bugs instead of one big project. I also read that, this method > was pretty successful closing about 100 bugs in one summer. A similar > approach can be taken in order to reduce the bug count in > bugzilla(current 1365!, 52 of them for 6.8) Agreed, That would be a very interesting project for GDB. > Another thing is, the coding begins on May 23 and according to the > release schedule gdb is planning its next release 15 days after that. > Those days might be rough for students assuming that the mentors will > be in a bug fixing/testing/documentation hurry and won't spend enough > time with their students. On the other hand(according to the release > schedule again), the students will have about 1 year after the summer > perfecting their implementations before the next-next(7.x?) > release(even though doing so is not obligatory). I think a worse period will be right before GDB branches on May 08, when we'll want to get the last patches in. According to the GSoC timeline, that's more or less when the "Comunity Bonding Period" starts. So mentors could be busy during the beginning of that period (not all of it, though). >From what I saw up to now, GDB releases are not a big burden (except for Joel :-) ). But perhaps this time we'll put in more effort since there are many features going in (big breakage potential), and now we have a bugzilla to track regressions from the previous release and try to get them fixed. Maybe we'll have a bigger focus on stabilization in the branch before the release... > Thiago > 3. Support pipes in the run command (this may be too small for a GSoC); > > I'm planning to spend some nights on this before GSoC starts. Nice. Let me know if you need help. I think you won't have to mess with ugly parts of GDB internals, so it's a good feature to start. Have you seen the DeveloperTips page on the GDB wiki? It links to a document from Jeremy Bennett which has a good explanation of GDB. There's also the GDB Internals document. It's very incomplete, but I think it's still useful to read it. -- []'s Thiago Jung Bauermann IBM Linux Technology Center