Product SiteDocumentation Site

2.3. Making Changes

The packages that ship with your distribution may not always fully meet your needs. This deficiency may be due to a missing flag during build time, or missing or incomplete functionality. This section focuses on how to implement package changes correctly, often with a higher front-end cost but a much lower long term cost.
Changes to a package or software application must meet the following standards. Refer to each upstreams project's preferred method of communication before requesting a feature or offering a patch.
Free Software Change Policy
MustSource/Content PatchesAll changes to an upstream application must be offered to the upstream project.
MustCompilation/Packaging ErrorsErrors found in the compilation or packaging of an application must be sent to package owner via the distribution's bug tracking or ticketing system.
MayWorkless RequestWhen sending a feature request or change it is customary to send a patch or suggested solution with the initial report. If this approach is not feasible because of time or technical constraints, the request may be sent without further work from the requestor. Any questions from upstream must be answered in a timely manner.
ShouldDistribution NotificationAny changes sent upstream should also be sent to the distribution with a link to the related upstream ticket or list if applicable.

2.3.1. Forking

Forking is a serious subject in free software. The choice to fork an application typically causes the number of developers working on it to drop. If the fork is maintained locally for individual use of The Fedora Project, the long term costs for maintaining that fork rise significantly. Generally a fork should be considered a failure of communication or negotiation.
Free Software Forking Policy
MustLocal RepositoryAll forked packages must be kept in a local yum repository. The repository layout should match that of the distribution in terms of version, architecture, and other segmenting. Then install an additional yum.repo file for your local repositories.
MayVersion ForkIf the distribution's package maintainer has refused or is unable to do a version update, you may fork and maintain a local forked copy of the package.
MayFeature ForkIf the distribution's package maintainer has refused or is incapable of enabling a feature, you may fork and maintain a local forked copy of the package.
MayFork MaintenenceIndividuals who chose to fork a package are responsible for maintaing that package and back-porting security patches.
MayUpstream ForkIf an upstream software project's direction has taken a direction that causes incompatibilities with the infrastructure environment or the platform needs, a project fork may occur. Consult related licenses and ensure that legal steps are taken to properly rename the project. The forked project should be developed in free software fashion, and efforts must be made to develop a community around it.
ShouldFork RemovalEach local fork should regularly be checked to determine if the distribution's package has comes into compliance with platform needs. If so, the local fork should be removed in favor of the distribution's package.