On 20.10.2011 23:27, Sam Ruby wrote:
> On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir <robw...@apache.org> wrote:
>> Now, for our SVN, we need to host the actual source of the MPL
>> components, since we need to build the binaries on the platforms that
>> we support. And in several cases we have patches the original source.
>> Is this a problem?
>
> That normally is highly discouraged / not allowed. Why can't the
> patches be contributed back to the original projects?
reasons why patches to external libraries exist include:
1) to add missing features/fix bugs.
these should usually be submitable to upstream;
reasons why they exist anyway:
a) the patch was submitted and accepted,
but OOo does not use the new release yet
b) the patch was submitted but upstream is unresponsive
c) the patch was submitted but upstream has NACKed it
d) the patch was never submitted because upstream is dead
e) the patch was never submitted upstream due to lack of time
2) to get it to build in our build system.
quite often some C/C++ library does not come with a build system that
works with MSVC on windows (and also OS/2), so we patch in some
dmakefile to get it to build (the dmake build system requires the
makefile to be in the same directory as the source files, hence the
patch), and perhaps a config header.
of course it does not make sense to upstream these patches.
3) the patch is actually taken from upstream, and backported to an older
version. this may happen for critical bugfixes (esp. security), when
there was not enough time to evaluate and test a full update to a new
upstream version.
a big problem in managing patches is that up until about 2 years ago, the
build system could only apply a single patch to an unpacked tarball.
so there are perhaps still some big patches left that contain fixes for
various distinct problems from various different categories. of course,
once you have a 10k-line patch like that it becomes all the more difficult
to figure out what the heck it does.
regards,
michael
