Re: [Gdbheads] Steering Committee nominations

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Feb 19, 2004 at 08:55:05AM +0200, Eli Zaretskii wrote:
 > > 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 don't think "read the code" makes any sense in this context.  David's
 > example was the merge of a branch, which a non-trivial number of the
 > existing global maintainers think is the wrong approach, and which
 > constitutes the full time work of probably a dozen programmers for two
 > years.  Even someone with a solid, fresh-vintage understanding of
 > everything ever written about compilers would have a lot of trouble
 > giving any kind of opinion about that code if they weren't also
 > intimately familiar with the existing code, not just a knowledge of its
 > general structure.


This example doesn't require the members of the SC to read the code,
because doing that wouldn't have helped.  Having a grasp of the level
of complexity of that particular task, and knowing some general
principles of good software engineering is plenty here.  In case I am
not making myself clear, you don't need developers directly involved
in this decision apart from them offering objective and unbiased
estimates of the amount of work involved going one way or the other.
Was there disagreement among the ssa developers about how much work
was involved?

I think that being part of the SC is not just a honorific position, it
requires some active participation and time commitment.  And I think
we are all in agreement on this, whether the members are also
developers or not.

Anyway, I totally agree with Eli about the fact that developers should
not be on the SC, given the current tension among us.  I'd like a more
unbiased body.  I don't want to find myself in another similar
situation a few months in the future.  Just saying "we hope that this
will not happen again" is not enough, given human nature.  Look at how
judicial systems work in most countries, lawyers, judges, jurors are
not usually intimately familiar with the matters they oversee.  There
is always a discovery phase that involves consultation with those
directly involved to collect all the facts.  The same would apply
here.  The SC would not be making decisions in a vacuum, we would be
in the loop.

We also should apply some critical thinking when replicating what GCC
does.  While the projects are very similar and there is interaction
among them, it doesn't mean that our situation is exactly the same as
theirs.  We can certainly look at their model, and possibly take
things from it, but we shouldn't apply it blindly.  I hope I am
stating the obvious here.

Independently of this, I would like to make the recommendation that an
exit criterion be decided for committee members.  Doesn't have to be
complicated or controversial, just a simple one, like, 'your last known
e-mail address is bouncing' or similar.