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 mostly agree with Daniel here.  We have too many single points of
failure.  I still have testsuite patches sitting in my tree, dating
months back since they were never approved.  Similarly, Daniel
probably has been held back more than once since I wasn't able to
review threads-related patches in a timely fashion.  I think we should
allow our global maintainers to approve patches even for parts of GDB
where we have a specific maintainer, if they feel they have the
necessary expertise.

Depends on what `single point failure' means. If you look through the MAINTAINERS file you'll notice that all but one of the problem areas is double, if not triple maintained. Even with all that dedundency, patches in certain areas continues to stall. While there might be three maintainers, the reality is only one or none are reliable.


The first, and most obvious thing is for the global maintainers to review their current number of responsibilities and compare that against their actual level of commmitment. I'm down to just target/arch, remote, mips and sim/ppc.

The second, is for maintainers to always be on the lookout for potential new maintainers (global or not) and, where possible, step aside to let new commers in.

Finally, the GDB `tradition' (that appears to have been forgotten) is to up front reach consensus on stuff so that the final patches are trivial to review. cf, the block.[hc] change.

enjoy,
Andrew



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