This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]