[cgl_discussion] patch sets and feature sets

Rod.VanMeter at nokia.com Rod.VanMeter at nokia.com
Thu Nov 7 09:34:32 PST 2002


[Apologies for the duplicate posting.  After we're
sure everyone has switched, I'll stop doing that.]

I took Mika's definitions and tried to put in some
more detail.  It's possible that I've simply made
things murkier; feedback, please!

		--Rod

Some definitions to start with:

Feature Set (FS): A Feature Set is a group of related features defined
by the xxx (requirements?) group of CGL, based on suggestions created
by the PoC group.  An FS will form the unit around which development
and testing are structured.  An FS will consist of a digestible amount
of work for distro vendors, who may choose to adopt functionality in
feature set-sized chunks.

[Mika's defn of Feature Set: Logic[al] division of requirements based
on feature dependencies, feature maturity, and mainstream acceptance
potential.]

Patch File (PF): a single file containing patches against one or more
source files.  No relationship is implied to a feature or feature set
or validatibility [sic]; a patch file is a snapshot of part of a
source tree at a point in time.

Patch Set (PS): One or more patch files and associated information
representing a single feature set.  There may be independent,
competing patch sets that implement the same feature set in different
ways.

A patch set supplies something against which validation tests can be
run, but passing the validation suite is not a requirement to be a
published as a patch set (indicating what the validation status is is
required).  The validation tests are likely to NOT be part of the
patch set, but are referred to externally.  A validation test suite,
if developed externally, will probably not correspond exactly to a
feature set.

A patch set must indicate the version patch files are to be applied
against.  For the kernel, this should be a kernel.org version number.
For user-level items, this should indicate the version number and
location of the original source.

The general goal of a patch set is to have a limited lifetime; ideally
the contents of the patch set will be merged into the mainline kernel
and tools in a few months to a year.  A few (such as anything based on
USAGI) are likely to exist for longer periods.

A Patch Set SHALL contain:
* the version number of the patch set
* the name and version number of the Feature Set it implements
* patch files for sources
* references to the original sources against which PFs are applied
  (N.B.: may be a kernel AND one or more sets of user tools, e.g. RAID
  management or network config)
* release notes on the status of the implementation and testing
* author, contact & license info

A Patch Set MAY contain:
* sources and instructions for any co-developed testing tools
* references to any external validation tools
* instructions on installation, if anything more than patches against
  a kernel.org kernel is included
* implementation design docs or references to them
* a config script and instructions on config options, if any exist

All of these may be presented in a single tarball or collected
together on a single web page.  A patch set will be publicly available
and shall be archived.

A Patch Set SHALL NOT contain:
* binary images
* the full original sources
* anything not related to the implementation of a Feature Set

[Mika's defn of Patch Set:
* Open source implementation of a feature set.
* There could be multiple patch sets per single feature set.
* Patch set done as open source project on a recognized open source
infrastructure.
* Two patch sets may implement the same group of requirements and/or
interface differently.]

Note that this talks about patches in source/text form.  For the
binary equivalents, substitute "package" for "patch".

Our goal is NOT to create an uber patch set that gives you an entire
CGL distribution as a product of our work, but to get our
functionality into mainstream code and distros.  Our end product,
then, is that adoption.  As a tool, we or someone else may create uber
patches that allow e.g. developers, ISVs, or early adopters to quickly
create CGL-compliant systems for their own experimentation purposes.
No support will be implied.




More information about the cgl_discussion mailing list