Re: [Gdbheads] Re: Feb's patch resolution rate

[Elena Zannoni]

David Carlton writes:
 > On Thu, 25 Mar 2004 18:51:56 -0500, Elena Zannoni <address@hidden> said:
 > 
 > > Your proposal has a fundamental flaw.  Trusting that voting achieves
 > > its purpose means to trust that people are acting fairly and that
 > > everybody's opinion gets a fair chance based on technical merit.
 > > Here you are, instead, openly stating that voting is about
 > > convincing people to be on your side, instead of believing that they
 > > can achieve an independent opinion on their own.
 > 
 > (Presumably, in the above, by "convincing people" you mean something
 > along the lines of "lobbying" as opposed to, say, "convincing via
 > technical arguments.)
 > 

yes, it's obvious that pointing out pros and cons of a technical issue
on technical grounds is necessary to achieve an opinion. That's
definitely not what I am objecting to, or worried about.

 > I guess what I don't understand is the details of the scenario that
 > you're envisioning where people achieve an independent opinion on
 > their own.  After all, if different people come to their own,
 > differing independent opinions on a patch, we can't allow all of those
 > opinions sway - we have to pick one of the options, lest GDB fork.
 > 

That's ok, if an idea or a patch is technically unsound, it should go
away and be defeated.  By achieving an opinion on one's own I mean
that the debates (or whatever you want to call them) should be in a
public forum, and of a technical nature only.  Free of interferences
from personal agendas.  I mean, an outsider could read the list, and
form an opinion based on that exclusively, being sure that only and
all what's on that list is an accurate representation of the issues at
hand.

Given what's happened, and the personal attacks I have seen in some of
Jim's e-mails, I hope you'll understand why I am worried.

 > Given that, I don't quite see how you think conflicts about patches
 > should be resolved.  Should they get kicked up to the newly reformed
 > steering committee?  Should they continue being resolved by the same
 > mechanisms that we currently have?  If the latter, how would you
 > describe the current mechanisms, and the way they play out when
 > parties can't come to a consensus?
 > 

I think that the current mechanism works in most cases.  I have had
arguments with you and others about patches, and those have been
resolved in a civil manner.  From what I have seen on this list, Jim
and Michael feel that they have a problem with Andrew, but I don't
think there are that many unresolved patches, if any, involving those
3 people.  The current method relies on a definite 'responsibility
chain' for which the 'buck' stops somewhere, clearly.  This is the
area maintainer, and if none exists, the head maintainer.  Note that,
contrary to what has been insinuated, being the person where the buck
stops is not just a position of power, but more one of responsibility.
If I maintain area X and I keep making poor technical decisions, or
not reviewing patches, I will be the one accountable for area X being
in bad shape or not performing well enough.  This is fine with me.

The proposal, including both global write privileges and voting,
shifts this balance of accountability, responsibility and (if you
really want) power, by deemphasizing accountability and interrupting
the continuity of direction that a single maintainer (or small group
of) provides.

I am favorable to sending those eventually unresolved issues up to the
SC.