increasing the number of GCC reviewers

Joseph S. Myers joseph@codesourcery.com
Wed Jun 10 12:47:00 GMT 2009


On Wed, 10 Jun 2009, Richard Kenner wrote:

> > > GCC isn't really like that. Changes in one part can affect things much
> > > later on, and you really have to know why. That doesn't mean you have
> > > to understand all of the compiler, but you need to have a lot of
> > > knowledge.
> > 
> > This is a problem with GCC's lack of modularity, not with Basile's
> > point of view.
> 
> I don't think it's a totally modularity issue.  Compilers, by their nature,
> are some of the most complicated and interdependent programs around.  Sure,
> one could improve the modularity of GCC, but a key to evaluating a change
> is to know if the change is being done in the right place.  In order to be
> able to make that determination, you have to know about all the other
> places that might also exist.  Modularity isn't going to help THAT problem
> much.

This is one area where reviews of the form "OK if there are (no objections 
/ no objections from an area X maintainer) within 48 hours" can be useful: 
if a maintainer can judge that a patch will safely fix a problem but it's 
possible that a maintainer from another area, or a more specific 
maintainer, might judge that a different approach for a fix would be 
better.  For that matter, a maintainer could comment on the choice of area 
in which to fix the bug without knowing about the precise details of how 
it should be fixed there; there are lots of partial review possibilities 
that already happen (and we don't need to classify them in detail, but may 
wish to encourage them where patches fall between maintainer areas).

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc mailing list