[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gdbheads] Steering Committee nominations
From: |
David Carlton |
Subject: |
Re: [Gdbheads] Steering Committee nominations |
Date: |
Thu, 19 Feb 2004 08:55:50 -0800 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) |
On 19 Feb 2004 08:55:05 +0200, Eli Zaretskii <address@hidden> said:
>> From: David Carlton <address@hidden>
>> * As Ian pointed out, it's sometimes important for the steering
>> committee to have a feel for the effects of changes on GDB's source
>> code. For example, I don't see how the GCC steering committee
>> would have been able to decide whether or not to merge tree-ssa
>> into GCC 3.5 without that sort of data.
> Sorry, I don't see the difficulty. Given enough technical
> information about pros and cons (if the available info is not
> enough, the committee members can ask questions and/or read the
> code), an experienced programmer with good understanding of GDB's
> use and general structure should have no problems of making such
> decisions. Software project managers do that for their living every
> day.
Well, sort of. My manager doesn't actually write code on the project
that he's managing, that's true. But he spends a huge amount of time
trying to understand the product, including quite a lot of technical
details about it. I don't think it's reasonable to demand that level
of commitment to GDB SC members who aren't active GDB developers.
> I'm also not sure that tree-ssa inclusion is a good example for the
> kind of arguments that are going on on GDB lists. Perhaps you
> raised it as an extreme case to make a point, in which case it
> should be treated as such.
I just raised it because it's the last GCC SC decision that I'm aware
of. I don't think the GCC SC spends a lot of time managing delicate
personnel issues; my hope is that, once we come to a resolution on the
issues at hand, the GDB SC also won't spend a lot of time managing
delicate personnel issues.
>> So, while I certainly wouldn't want to require all SC members to
>> follow gdb-patches, I think it would be bad if none of them
>> understood the details of changes, which probably in practice means
>> that several (most?) of its members should be active developers.
> I don't see how do you make the leap of logic between ``none of them
> understood the details of changes'' and ``in practice [committee
> members] should be active developers''. I think this requires
> explanation. In particular, how hard it is, in your opinion, to
> understand the details of the changes? A good programmer should be
> able to read code written by others and understand what it does
> without any difficulty, don't you think?
No. Maybe I'm a bad programmer, but when I first started working on
GDB, it probably took me a month (admittedly, not a month solely
devoted to GDB, I had a day job as well) before I could fix bugs that
weren't purely local, that depended on global assumptions about data
in GDB. And that's just to fix concrete bugs; it took me another few
months before I could start trying to figure out how to untangle and
simplify those global functions, to try to make progress at a higher
level.
Also, it depends not only on the programmer but on the code in
question; I would not hold up GDB's code as a model of transparency.
> In fact, every global maintainer does precisely that when they
> review patches in an area that is not their direct responsibility.
> If we can do that, why cannot others?
Others can, if they are as familiar with GDB development as global
maintainers are, and if they follow gdb-patches regularly. The point
of my "in practice" above is that I don't think there's this huge pool
of people out there who follow gdb-patches regularly, who have a
pretty solid understanding of GDB's code, and who would be interested
in being GDB SC members yet aren't active GDB developers.
>> * I think there will be authority problems with the SC if none of its
>> members are active GDB developers. GDB is a volunteer project; it's
>> hard to get volunteers to follow orders if the people making those
>> orders don't have authority coming from their actions within the
>> project, not just from their presence on a list somewhere.
> I don't see this that way; authority does not have to come from
> intimate involvement in the day-to-day technical activity. It could
> come from good leadership, sound decisions that the troops learn to
> respect and value, and general ability to act as an arbiter. I have
> numerous examples of such sources of authority, let me mention just
> two: Richard Stallman (in many GNU projects) and Ian Taylor in the
> discussions here during the last few weeks.
That's a good point: I am convinced that Ian would be a a valuable
member of the GDB steering committee. Then again, that's because I've
actually been participating in a discussion with him recently. If
there were lots of members of the GDB SC who never posted to any GDB
mailing lists, I think that could be a problem, no matter how wise
they were. But I may well be in a minority in that view.
David Carlton
address@hidden
- Re: [Gdbheads] Steering Committee nominations, (continued)
- Re: [Gdbheads] Steering Committee nominations, Eli Zaretskii, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations, Robert Dewar, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations, Richard Stallman, 2004/02/20
- Re: [Gdbheads] Steering Committee nominations, Robert Dewar, 2004/02/20
- Message not available
- Re: [Gdbheads] Steering Committee nominations, Robert Dewar, 2004/02/20
- Re: [Gdbheads] Steering Committee nominations, Eli Zaretskii, 2004/02/21
- Re: [Gdbheads] Steering Committee nominations, Michael Snyder, 2004/02/24
Re: [Gdbheads] Steering Committee nominations, David Carlton, 2004/02/18
- Re: [Gdbheads] Steering Committee nominations, Eli Zaretskii, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations, Andrew Cagney, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations,
David Carlton <=
- Re: [Gdbheads] Steering Committee nominations, Daniel Jacobowitz, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations, Robert Dewar, 2004/02/19
- Re: [Gdbheads] Steering Committee nominations, David Carlton, 2004/02/19
Re: [Gdbheads] Steering Committee nominations, Elena Zannoni, 2004/02/19
Re: [Gdbheads] Steering Committee nominations, Daniel Jacobowitz, 2004/02/19
Re: [Gdbheads] Steering Committee nominations, Andrew Cagney, 2004/02/23
Re: [Gdbheads] Steering Committee nominations, Richard Stallman, 2004/02/24
Re: [Gdbheads] Steering Committee nominations, Jim Blandy, 2004/02/24
Re: [Gdbheads] Steering Committee nominations, Andrew Cagney, 2004/02/24
Re: [Gdbheads] Steering Committee nominations, Richard Stallman, 2004/02/26