This is the mail archive of the gdb@sources.redhat.com 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: [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



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