[Gdbheads] A small patch case study, -file-list-exec-source-files

[Michael Snyder]

Ian Lance Taylor wrote:
> Joel Brobecker <brobecker@gnat.com> writes:
> 
> 
>>GDB is a volunteer work!
> 
> 
> I want to note that this is only partially true.  In fact there are a
> number of people who are paid to work on gdb.  It's not clear whether
> anybody is paid specifically to maintain gdb.  When I was at Cygnus I
> was paid to maintain the GNU binutils, though that was certainly not
> my only job.  I don't know whether Red Hat has carried that sort of
> thing forward.

Well now... there's a fine point here.  Red Hat, Monte Vista, Apple,
HP, and other organizations may pay some people to work on GDB, but
only in some limited sense do those organizations pay their employees
to review other people's patches.  And to whatever degree that is true
(eg. my job description does include spending a certain part of my
time working as an FSF maintainer), all it does is modify who's doing
the volunteering: to some degree it's me, and to some degree it's
Red Hat.  It's still donated work, the FSF isn't paying for it, and
I'm still 100 percent a volunteer.  I wouldn't lose my job if I
announced that I didn't want to serve as an FSF maintainer any more.
All that would happen would be that the work load of the other
maintainers would go up, since they would have to review all of
my work.

>>If you keep insisting that a maintainer have to review patches within a
>>given timeframe and that they should step down if they can't, then I
>>think we're going to lose a lot of maintainers. Will GDB really be
>>better off? I think not.
> 
> 
> I would say that the issue is how to best keep gdb moving forward.

That is one valid way of looking at it, Ian, but it isn't the only
way.  All of us maintainers are people too, and it's perfectly
legitimate for us to have our own agendas and our own interests
in mind, in addition to those of gdb and the FSF.  By becoming
FSF volunteers, we did not become monks -- we did not give up
the right to our own self-hood and our own egos.

To make a team work, we have to get those egos to function smoothly
together -- but that doesn't mean pretending that they don't exist,
or making decisions on the basis that the only thing that matters
is gdb.  The people working on gdb matter too.

> On the one hand, if we require prompt patch review, then gdb may lose
> maintainers.  On the other hand, if patches are not reviewed promptly,
> then gdb may lost contributors.  There is a balance between the two.
> The goal is to keep the balance from tipping too far to one side or
> the other.
> 
> I don't know myself whether the balance is indeed tipped too far for
> gdb.  As I've said, I do think that maintainers should treat patch
> review as their most important activity.
> 
> 
>>I think you're looking at the wrong solution. The real solution,
>>according to me, is not to push away good maintainers that have only so
>>much time, but to help the group of maintainers to act as a team.
>>When one maintainer is too busy, then the rest of the team should be
>>allowed to step up and help the busy maintainer by reviewing patches
>>and answering emails in his place. The real problem is that GDB
>>currently has bottlenecks, and that's the issue that needs solving,
>>one way or the other.
> 
> 
> Yes, this sort of approach has been proposed by several different
> people, including some gdb maintainers.