This is the mail archive of the gdb-patches@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: [Gdbheads] A small patch case study, -file-list-exec-source-files


> If you feel that your contributions are reviewed in reasonable time,
> _you_ don't need to complain or ask for better response times.
> 
> But other contributors felt differently.  We didn't just invent that,
> there are threads in the archives that show that this did in fact
> happen.  As long as any of the people who contribute code feel that
> some of their contributions take too long to review, we as maintainers
> need to do some soul searching to find ways to avoid such feelings.

Right. I guess I wasn't clear in my previous message, sorry. I am not
saying that everything is fine. I am just reacting to the idea of
forcing maintainers to review within a hard timeframe each patch that
touches some code they maintain. At least that's what I understood from
Bob's message.

I also have some patches that have been sitting unreviewed for a long
time. I would sure like to see the process become better, and I think
we can improve. But I think the solution to this problem lies in better
teamwork, not in asking maintainer to review "their" patch within a
short timeframe or else quit. I say "their patch" because right now, we
have areas of code where only one or two maintainers can do reviews, and
that to me is the real problem, and probably the source of many of the
delayed patches.

That's why I was in favor of the proposal that asked that global
maintainers be allowed to review and approve patches anywhere.
GCC does it, AFAIK. I think this is going to help GDB in that
respect. Or does anybody have any evidence of the contrary?

-- 
Joel


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