Re: [Gdbheads] Steering Committee nominations

[David Carlton]

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