Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

[Miloslav Trmač]

On Mon, Feb 27, 2012 at 4:18 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
>
>> Personally, my stance on this is that, provided that the forks are
>> properly renamed such that they will not conflict with other forks of
>> the same codebase, there's no reason to disallow them. As mentioned by
>> Toshio in the ticket, carrying forks provides a much better alternative
>> to bundled libraries in the situations where the primary codebase is
>> lacking certain features.
>
> There's exactly the same reason to avoid closely-related forks as there
> is to avoid embedded libraries - if you have a security issue you now
> have more places to fix the same bug. The question is whether that cost
> is larger or smaller than the gain from carrying the forked code.

There is one crucial difference: A maintainer of a forked code base
explicitly knows he is maintaining it; a maintainer of a software
package that happens to embed a library may not think about
maintaining the embedded library at all.
   Mirek