Re: CVS commit: src/external/bsd/mdocml

[christos%astron.com@localhost (Christos Zoulas)]

In article <20110818142524.GA26040%britannica.bec.de@localhost>,
Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>On Thu, Aug 18, 2011 at 01:47:19AM +0000, Christos Zoulas wrote:
>> In article <20110817212805.GB16537%britannica.bec.de@localhost>,
>> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>> >Could you please stop randomly changing 3rd party code without
>> >contacting the maintainer?
>> 
>> Unless the rules have changed, for simple compilation fixes we don't do that.
>> Otherwise the overhead of doing so would be too large. In this particular
>> case, do you have a different/better way of fixing this? If yes, I'd like
>> to know now.
>
>How can it be a simple compilation fix if you also change the Makefile?
>You are craeting additional work for every future import without
>providing much value. This is not specific to this case, but many other
>of your recent changes to stuff that can just as well be changed
>upstream first and reimported later.

There were two separate things I was doing in the past two days:
- Cleaning up all the XXX gcc4.5 changes that needed to edit both the
  Makefiles that contained things like -Wno-error, and fixing the sources
  to eliminate the errors.
- Auditing the code for printf format errors and fixing them. This requires
  adding -Wno-format-nonliteral to the cases that we have to use non literal
  format strings or fixing the code to make strings constant where possible.

Every project I know off makes changes locally first and then pushes
them upstream. It is not practical to wait for upstream to be fixed
first, specially in cases of security fixes. In some cases we
maintain many thousands of lines of diff just because upstream will
not take them, and the version control systems do a pretty decent
job merging new vendor branches.

christos