Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gcaiod-ooo-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: ooo-dev@incubator.apache.org
From: Michael Stahl <mst@openoffice.org>
Subject: Re: Clarification on treatment of "weak copyleft" components
Date: Sun, 23 Oct 2011 23:31:37 +0200
Lines: 45
Message-ID: <j8213q$hik$1@dough.gmane.org>
References: 
 <CAP-ksog4_h6HOxpAAGfyG5s4TK_eJGAydc5PDPqoXg6g=RP-Lg@mail.gmail.com>
 <CAFG6u8EtyPhC2GOZq-03CqHFM0+qWTsKH1SmnqHjVyXF+pgOYQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:7.0) Gecko/20110927 Thunderbird/7.0
In-Reply-To: 
 <CAFG6u8EtyPhC2GOZq-03CqHFM0+qWTsKH1SmnqHjVyXF+pgOYQ@mail.gmail.com>

On 20.10.2011 23:27, Sam Ruby wrote:
> On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir <robweir@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