From Fedora Project Wiki
(Drafting some potential bundling library exceptions)
 
(Bundling proposals updated)
Line 1: Line 1:
{{draft}}
{{draft}}


There are multiple ways that we could consider relaxing the bundling guidelines.  Collecting the ones that we've recently wanted to apply to a variety of situations here.
There are a few proposals for new criteria for allowing bundling of code.




== Active upstream Security Team ==
== Active upstream Security Team ==


Another thing that might be viewed favorably by the FPC is if
One thing that the FPC would consider would be whether the:


# Project is actively developed and has a responsive upstream, with new
# Project is actively developed and has a responsive upstream, with new
   releases occuring at least yearly. Rationale: a) if a security issue
   releases occurring at least yearly. Rationale: a) if a security issue
   does arise, we don't want to be left on our own; b) where projects
   does arise, we don't want to be left on our own; b) where projects
   have bundled code but are not fast-moving, the reward/work ratio of
   have bundled code but are not fast-moving, the reward/work ratio of
Line 15: Line 15:


'''AND'''
'''AND'''
# Project has an active security response team of its own
# Project has an active security response team of its own
   and has demonstrated both the ability and the will to release timely
   and has demonstrated both the ability and the will to release timely
Line 23: Line 24:


'''AND'''
'''AND'''
# The upstream  project is actively working on unbundling.
# The upstream  project is actively working on unbundling.


We'd also allow forks of such projects in.
Like most of the possible criteria, this rationale may not be sufficient in and of itself but it may be one thing that we'd take into consideration.


== Too Big to Fail ==
== Too Big to Fail ==


Although it is a case of last resort that FPC is extremely reluctant to allow, we occasionally consider whether a package is too popular to keep out of the distribution.  FPC  
Although it is a case of last resort that FPC is extremely reluctant to allow, we occasionally consider whether a package is too popular to keep out of the distribution.  In a case like this, the package is seen as necessary enough for Fedora's end users that we'll grant a one-off exception for it.  Note that this sort of exception is really distasteful to FPC so other finding other criteria in addition to this would definitely help your case.


== Too small to care ==
== Too small to care ==


FPC may grant an exception if we deem that a package is niche enough that a vulnerability or unaddressed bug in the package is not a high risk to the vast majority of Fedora users.
== Bundling by projects which are forks of other products that have been granted an exception ==
In some cases we grant an exception to one package that depends on something intrinsic to the project creating the package rather than the code.  Examples of this are when we grant an exception for code that originates with the same upstream or when we deem that a package is too popular to keep out of the distribution.  Forks of these projects often don't fall under the same exception.  (A fork of firefox is likely not going to fall under the popularity argument as firefox does.  A fork of gdb won't get the "same upstream" exception to bundle the binutils libraries as gdb itself.)
FPC might consider granting an exception for these packages if it's demonstrated that upstream is good about syncing its code with changes from the source it forked from.  If this is not the case, FPC is unlikely to grant an exception based on this but may grant one based on other criteria.


[[Category: Packaging guideline drafts]]
[[Category: Packaging guideline drafts]]

Revision as of 20:12, 31 March 2014

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

There are a few proposals for new criteria for allowing bundling of code.


Active upstream Security Team

One thing that the FPC would consider would be whether the:

  1. Project is actively developed and has a responsive upstream, with new
 releases occurring at least yearly. Rationale: a) if a security issue
 does arise, we don't want to be left on our own; b) where projects
 have bundled code but are not fast-moving, the reward/work ratio of
 unbunding the code is higher.

AND

  1. Project has an active security response team of its own
 and has demonstrated both the ability and the will to release timely
 security updates when issues are discovered in bundled code.
 Rationale: this reduces the burden on our security team, and does not
 put Fedora maintainers in the position of creating or carrying our own
 patches.

AND

  1. The upstream project is actively working on unbundling.

Like most of the possible criteria, this rationale may not be sufficient in and of itself but it may be one thing that we'd take into consideration.

Too Big to Fail

Although it is a case of last resort that FPC is extremely reluctant to allow, we occasionally consider whether a package is too popular to keep out of the distribution. In a case like this, the package is seen as necessary enough for Fedora's end users that we'll grant a one-off exception for it. Note that this sort of exception is really distasteful to FPC so other finding other criteria in addition to this would definitely help your case.

Too small to care

FPC may grant an exception if we deem that a package is niche enough that a vulnerability or unaddressed bug in the package is not a high risk to the vast majority of Fedora users.

Bundling by projects which are forks of other products that have been granted an exception

In some cases we grant an exception to one package that depends on something intrinsic to the project creating the package rather than the code. Examples of this are when we grant an exception for code that originates with the same upstream or when we deem that a package is too popular to keep out of the distribution. Forks of these projects often don't fall under the same exception. (A fork of firefox is likely not going to fall under the popularity argument as firefox does. A fork of gdb won't get the "same upstream" exception to bundle the binutils libraries as gdb itself.)

FPC might consider granting an exception for these packages if it's demonstrated that upstream is good about syncing its code with changes from the source it forked from. If this is not the case, FPC is unlikely to grant an exception based on this but may grant one based on other criteria.