From rPath Wiki

rPath Linux Project Rules

This list is the beginning of our attempt to express some of the rules we use to develop rPath Linux. It will never be complete; right now it's a trivial beginning; a placeholder.

General rules to follow for commits intended for rPath Linux:

1. We do not add new packages to the distribution without discussion
2. rPath Linux per se is Open Source:
   1. Licenses need to be sufficiently compatible -- ask if you are unsure
   2. :source components must not be archives of binaries in rPath Linux, so no BinaryPackageRecipe or equivalent
3. When possible, have as few patches as possible. Follow upstream as much as possible. Exceptions to this rule will tend to be for one or more of the following reasons:
   1. Keeping compatibility with common practices that we have implemented (such as user-private groups)
   2. Keeping library compatibility with some other distributions where it is important to do so (for example, if there are major proprietary applications that link against those libraries).
   3. Having a maintained software stream for software that is not really being maintained upstream and we have to pull from somewhere. Fedora isn't a bad choice for that for many things, particularly because we have many similar conventions (like user-private groups). For other things, we pull from Debian. There's no point in re-inventing the wheel in these cases. Of course, when we do this, we should be sending any further general patches we create upstream to the location from which we pull.