Re: [wwwdocs] Move all documentation projects to a new page

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 22 Nov 2004, Steven Bosscher wrote:

> > If the text of any project description has changed, please submit the
> > change of text as a separate patch from the move to a separate page.
> 
> I am not going to do that, sorry.  You have many comments on each
> patch I submit, which is fine normally.  But this one, I'm not going
> to address your comments, they only cause more work for me. 

Submitting patches in a form that is easy to review is important for all 
submissions, not special to this.  If text is both changed and moved, 
effective review of the changes means the patch that makes the changes 
should be separate from the patch that moves the text without changing it 
so the diff genuinely shows the specific changes being made.  (I don't 
mind which order the two patches go in, and don't feel that each separate 
change to the text of a project needs its own patch.)  I expect the 
individual changes will generally be useful and desirable; but the 
description of the patch as submitted suggests that some changes to 
individual projects may be hidden in the move to a new page.

> And FWIW I don't see your name listed as a web pages maintainer.

I will note the problems with patch submissions that fail to follow 
submission guidelines, or imply that they may well fail to follow such 
guidelines (in this case submitting patches in minimal indivisable units) 
in a way that makes them difficult to review, regardless of the area of 
the compiler involved.  All the objections to the former system for 
submission of Ada patches were no less valid for not coming from Ada 
maintainers.

I will object to patches that don't follow the GCC Coding Conventions, 
regardless of the area of the compiler involved.  In such cases (for 
example, missing documentation), I would also consider it dubious for 
someone to check in a patch with a known failure to follow the 
requirements on the approval of someone with the necessary authority 
unless that approval explicitly acknowledges the deficiency and approves 
the patch notwithstanding it: I don't think an accidental approval (where 
the approver didn't notice the deficiency) is sufficient approval if the 
deficiency is pointed out before the commit.

I will also generally be more critical of patches when commenting on 
patches in areas I don't maintain than when reviewing patches in areas I 
do, as such comments clearly cannot be construed to block a patch in the 
way a maintainer comment could when a relevant maintainer can make an 
approval which explicitly approves a patch notwithstanding its 
deficiencies.

(In this case, I consider that I could as docs co-maintainer review a 
patch to the lists of documentation projects: the project lists for a part 
of the compiler are included in maintaining that part of the compiler.  
But while I may leave the actual review to Gerald, I still want to see the 
patch in suitable form for *all* readers of gcc-patches to see at a glance 
what the individual logical changes are - just as with patches to other 
parts of the compiler I would never review.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)