This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Maintainer policy for GDB


> Date: Thu, 17 Nov 2005 15:10:20 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> 
> About the voting system: I would also prefer to avoid this. The history
> of the GDB maintenance community since I joined shows that we're able
> to work together without unsolvable disagreements.

How far into the past does your history go?  I've seen unsolvable
disagreements less than a year ago.

> In case a disagreement happens and cannot be resolved, which should
> be very seldom, the persons involved should present our arguments to
> the SC, and the SC makes a decision.

I thought we wanted to minimize SC involvement.  If that's true, we
should try to actively avoid situations where we need to go to the SC,
not simply assume they will happen seldom enough to be insignificant.

One problem with going to the SC is that their procedures take a lot
of time.  See how much time it took to resolve the last feud we had.
I think we don't want the adverse effect the SC's slow judgement has
on GDB development.

> I agree with Eli that an abusive developer/maintainer may happen again
> in the future. But I disagree that we should enforce stricter rules to
> prevent this from happening. This would be a waste of everybody's time
> for a situation which can only potentially happen very seldomly.

What ``waste of time''?  It normally takes a few day--a week, say--to
wait for objections, comments, etc.  We could limit that period to
something reasonable, like 10 days.  We could do any number of other
things to prevent the delay from getting unreasonably long.  What I
cannot understand is why people are arguing for DOING NOTHING AT ALL.

> How many developers have been bulies in GDB in the past 5 years?

One thing I've learned about risk management is that you need to
consider the damage caused in case an event actually happens, not only
the probability of the event.  Some events are so damaging that you
might take extreme measures to make sure they never happen again.

> Let's not penalize the "nice guys", the majority of you, and deal with
> the few "bad guys" when the situation demands it.

I hate to lecture, but let me remind you that laws were invented
because leaving rules of conduct to the people, assuming they are
reasonable and fair, was found to not work.

More to the point, if the ``penalty'' is reasonably tolerable, I don't
understand why we cannot ``penalize'' ourselves a bit, if in return we
regain trust and cooperation.

Let me say this in another way: This community, good-willing as
it may be, failed a serious test of its ability to cooperate just a
few months ago!  Isn't it reasonable to step back a bit and practice
self-restraint for a while, until we have more than a few months of
good cooperation behind us?

> So let's say we end up having somebody who is abusive and doesn't change
> his behavior after discussing the problem. Then let's collect the evidences
> of his behavior, and present them to the SC, who can then decide to revoke
> or not the priviledges that he's abusing from.

That's not what happened last time.  Experience should teach us that
such situations tend to create much uglier dynamics than the idyllic
picture you envision.  Somehow, that experience taught us nothing, or
so it seems.

Or maybe it's the old man in me talking, I don't know.

> > (Why CC everyone, if we all read the list?)
> 
> I like this practice, because emails with my name in the recipients
> have a little flag, so I pay more attention to them (and look at them
> first). This is an easy way to make sure that the message gets some
> people's attention.

Since Daniel sets up his mailer to prevent replies getting to him by
direct email, I find it ironic, to say the least, that he forces us to
get the same message twice.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]