on reputation and lines and putting things places (Re: gcc branches?)

[Joseph S. Myers]

On Sun, 8 Dec 2002, Stan Shebs wrote:

> Now, almost all of *my* merge difficulties have been because Apple
> changes to GCC are logically contradictory to FSF code.  Does arch

Similarly, a common occurrence is that a new target, developed for some 
time in an external tree, is merged in, but it follows older coding 
standards and does not take account of global cleanups done to the main 
tree in the mean time.  How could arch tell that, say, FRV's xm-frv.h file 
ought to have been removed when xm-files.h were removed generally from the 
main tree, and the presence of such a file is a conflict, or that a 
particular target macro should have been removed (except that we use 
#pragma GCC poison to ensure that part), or that a certain coding style is 
obsolete, or that all occurrences of a spelling error had been fixed, or 
that something now needs documenting?

That sort of problem is what *I* generally see as merge problems - failure
to follow coding standards, especially as regards to documentation
(including comments), when patches are submitted, even though the issues
involved have been cleaned up in the tree before.  (And I include in this
small patches that didn't need a branch - if a patch is submitted that
includes some particular Texinfo error, when all such were previously
fixed, there's a logical conflict in that the new code would have been
fixed if it had been there previously.)  The basic mechanics of merging to
and from branches (a rare event, in any case) seem to work fine, the
logical aspects of keeping track of cleanups and refinements to coding
standards (involving in principle remembering on the order of a GB of mail
to the lists since the start of EGCS, though we try to include
documentation to reduce the effects of the impracticability of remembering
all the mail) need continual reminders to patch submitters to include
docs, or testcases, or that something in their patch is obsolete, or
misspelt, or will be ugly in the printed manual, or bad style.

-- 
Joseph S. Myers
jsm28@cam.ac.uk