Re: google summer of code

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

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