#265 Forking's intersection with bundling
Closed: Fixed None Opened 11 years ago by toshio.

I'm opening this because it's implicit in our treatment of bundled libraries but should probably be explicitly stated. I'm going to pycon for two weeks but I'll work on turning these thoughts into an actual draft when I get back.

This addresses concerns raised in
https://bugzilla.redhat.com/show_bug.cgi?id=915082 about the nodejs-deep-equal library/package.
I think it also would apply to https://fedorahosted.org/fpc/ticket/248

We (FPC) like to avoid forks. However, when a new library is created that forks some other project in order to improve on the functionality because the originating upstream is not willing to do that, we still consider that a win overall. By making the improvements into a library that multiple projects can use the hope is to cut down on number of bundled instances and consolidate other projects on a single implementation (the new library that contains the improvements).

We most often encounter this situation when we're talking to a maintainer or upstream about a case of bundling and convince them to instead release their forked library separately for all to use and improve as a compromise but the idea should hold for cases where this is proactively done as well.

If we did have any questions they would probably be:
Did the forking library try to get their changes incorporated into the original library? What was the result?
How open are the developers to new changes from other sources? The idea is to promote consolidation of changes into one codebase.


I guess nothing ever happened here. I don't disagree with the overall sentiment, but I guess we'd need to see that draft.

Yeah, feel free to close. If someone else has the time and inclination they can start fresh or look to this bug for ideas.

Login to comment on this ticket.

Metadata