This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
I agree with what Daniel has said here. I'm concerned that some
people have misunderstood his points, so I'll put it differently.
I think GDB could get better use of the contributors it has now by
adjusting the rules for patch approval.
- Slow patch review is a real problem on GDB --- even acknowledging
the legitimate reasons for some delays that Elena has mentioned.
I found myself babysitting a short list of largely dormant maintainers
using regular pings. That was grosely inefficient. I've now given that
one up and have moved on to filing unreviewed patches in the bug
database - worse for the contributor waiting on a dormant maintainer but
better for me and the other active maintainers.
It has been in place for ~a month and, in my opinion, has definitly
improved things. There is a one-stop-shop where active [global]
maintainers can either find a backlog of patches or areas that need work.
I just wish that the tool being used was less primative :-(
- It's true that "... some maintainers should try to review patches in
their areas of responsibility more often", but merely saying so
doesn't have any effect. Folks have been saying that ever since
Cygnus loosened its grip on GDB and the process opened to the
public. That statement seems to express a hope that the maintainers
will somehow "wake up" and everything will get better. It's been
years, now, and we need to stop waiting for this to happen. Let's
work with the people we've got, rather than hoping they'll transform
themselves somehow.
And the vast majority of maintainers do a pretty good job.
- If we accept that the maintainers' behavior is stable, then the next
alternative is to adjust the organization that they operate under.
Is there some way to re-organize the people we have, accepting their
job committments and personal limitations (I have myself in mind
here as much as anyone else, so don't be affronted), so that things
progress better? Is the current organization optimal?
Stable or reliable? Most maintainers are reliable, a small few, though,
seem to keep falling asleep at the wheel.
Having such people as developers isn't a problem. Having such people
hold key responsabilities (such as being in the loop to review patches) is.
Andrew