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@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
