gdb-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gdbheads] Steering Committee nominations


From: Eli Zaretskii
Subject: Re: [Gdbheads] Steering Committee nominations
Date: 19 Feb 2004 08:55:05 +0200

> From: David Carlton <address@hidden>
> Date: Wed, 18 Feb 2004 10:49:04 -0800
> 
> * 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.

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.

>   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?  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?

> * 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.

Anyway, I don't want this to look like my personal crusade.  If mine
is the minority view, if most of the others do want to see people who
started this fight sitting on the committee and don't see any problem
with such a setup, I will shut up and do my best to get along.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]