On Mon, Feb 27, 2012 at 4:18 PM, Matthew Garrett <mjg59(a)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