This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Maintainer policy for GDB
> Date: Fri, 25 Nov 2005 16:38:49 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Fri, Nov 25, 2005 at 11:02:49PM +0200, Eli Zaretskii wrote:
> > If that is so, we will watch most of the current maintainers being
> > politely asked to step down. When the last of them goes, you can then
> > have your suggested approval procedure, since most areas will be left
> > without RMs ;-)
>
> Hmm. We can manage better than that. But, let's worry about the
> details of that a little later in the process, please.
>
> We need a concrete value for N. Joel has suggested anything from a
> week to ten days. I would prefer a week or less. Chris suggested a
> month, you suggested three weeks in response.
>
> Can we all reach compromise on two weeks?
I've not contributed much to this discussion. For one thing I've not
had too much time over the past two weeks to actively participate, and
the time I had, I spent on writing code and fixing bugs. I really
think that at most we need a set of guidelines; not a set of spelt out
rules. I let the time I wait for approval depend on several factors:
when my change is complex, invasive, etc. I'll probably wait months
before I'll commit the patch without explicit approval. If the patch
is borderline obvious, I'll usually ask for objections and commit if I
don't see any within a few days. I'll also check whether I see any
posts from the responsible maintainer on the list. If he/she is
usually very active, but not posting to the list for a while, I'll
just wait until he/she is back again. I think in general this works
pretty well, and if for some reason a particular maintainer expresses
his/her unhappiness with my action I try to change my behaviour. I
think that's the way we should interact with each other.
Yes we had problems in the recent past with a particular maintainer.
But I still think the other maintainers (including myself) are partly
to blame for that situation. Trust between maintainers was broken,
but you're not going to restore that trust by formulating some strict
rules.
Mark