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

[Matthew Garrett]

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.

Simple thought experiment: memcpy() has always obviously had destination 
and source the wrong way round. I can easily fix that in a forked glibc, 
but then I need to rebuild the entire stack on top of that to fix up all 
the callers. I think everyone would agree that that was unreasonable. 

There's a continuum here, rather than a bright-line test. Any decision 
we make (other than "accept everything" or "reject everything") is 
going to be somewhat arbitrary.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org