This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Re; Maintaining, was: Re: Reduce Dwarf Debug Size


On 3/1/07, Mike Stump <mrs@apple.com> wrote:
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
> Also I think GCC is doing the correct thing right now with respect of
> approving patches.  Yes in the past we were not as good but now we
> have corrected those mistakes.

So, are you saying that an 18 month review process isn't a mistake,
or that it has been corrected?  Likewise for patches that require 4-5
pings?  I'm not sure I see what you meant yet.

No I am not saying that. I am saying that those patches might not be worth commenting on. If you feel they are worth commenting on, then comment on them but I don't see you commenting on those patches at all. I have not seen any patches that require 4-5 pings, plus people have off weeks/months so somethings it might not look any one cares when in reality they do but they have not gotten to those patches yet. I think you are going down the wrong road when talking about patches and committing rights. If you want something new and the something new is execting to everyone, the patch will be commented on right away. And if nobody cares about the patch that much, it will go down the way side. This is common in all code development (and in life in general really). If someone wants a patch committed they will ping it a couple of times and if they lost interest because they now decide it is not a good thing or they no longer care about it, it will just fall down the way side. I don't think this can be solved via any other method really because the method you asked about is actually worse because usually if people post 100 good patches in row, there will always this one bad one. Witness RTH's tls one right before 4.2 branched, it was not updated for the section anchor changes and caused a regression under AIX. This was RTH's one bad patch in 1000 or so. The reason behind maintainership is because they have shown knowledge of that section of code and can improve it without being hand held. This is really the same answer you gave, just the way we decide who gets that honour is different.

-- Pinski


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