[wwwdocs] Move all documentation projects to a new page
Joseph S. Myers
joseph@codesourcery.com
Mon Nov 22 02:12:00 GMT 2004
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)
More information about the Gcc-patches
mailing list