This is a proposal for a process for taking desktop standards and formally identifying them as finished and ready for general use.
The standardization process is driven off a release schedule. freedesktop.org specification releases occur every 6 months. Release 1 will occur on 21 February 2005. For each release, specification versions can be proposed, and if a proposed specification version meets all the milestone for the release it will be incoporated into the release. Note that a release contains particular specification *versions* not specifications.
If we look at the process from the point of view of an individual specification version, there are the following stages:
Proposed*. The specification version is proposed for inclusion in a particular freedesktop.org
- specification release. The proposer owns driving the specification version through
the remaining stages. They are subsequently referred here as the owner. The proposal must contain a pointer to a draft of the specification as it currently exists, a component in bugzilla.freedesktop.org where comments on the specification can be filed, and a mailing list where discussions should occur. (In many cases, the appropriate list will be xdg@lists.freedesktop.org)
Beta*. The owner posts a version of the specification that he thinks should be the
final version of the release. Posting a beta specification starts a comment period that last for 3 weeks. New comments can't be filed after the comment period closes. During this process new beta versions can be posted, the owner decides whether posting a new beta version pushes out the close of the comment period or not.
Candidate*. the comment period has closed and the owner has addressed all submitted
- comments by editing the spec, or by marking them wontfix or deferred with an explanation. A new version of the spec is posted. Posting a candidate specification
starts a review period that lasts two weeks. The purpose of the review period is to allow anybody to remark on whether they think comments have been properly addressed and whether they think the specification version should be released.
Released*. The review period has closed, and the freedesktop.org specification release
- coordinator has signed off that they think that there is consensus on the specification version and that it meets the general guidelines for specifications.
- specification release. The proposer owns driving the specification version through
The general guidelines for specifications are the following:
complete*. The specification should completely describe the interaction between
- applications or between the application and the desktop.
implemented*. There should be multiple independent implementations of the
- standard that have been tested to interoperate.
Release schedule
The schedule for a freedesktop.org specification release works as follows:
- T - 4 months: Deadline for proposals
- T - 3 months: All proposed specification versions must be in the Beta phase
- T - 1 month: All proposed specification versions must be in the Candidate phase
- T - 1 week: All proposed specification versions must be Released
If a specification misses one of these deadlines it won't be part of the release and must be proposed again for the next release.
Comments
Discussion of a specification is centered around comments. A comment could also be called an issue or a bug; it's just a single issue that someone has with the specification. Comments are filed as bugs in bugzilla.freedesktop.org; before a specification enters the Candidate phase, each comment much be resolved by the owner in one of three ways:
- Marked fixed; the spec has been edited to resolve the comment.
- Marked wontfix; the comment is either considered not to be a
- real issue, or one that can't be resolved while maintaining compatibility with earlier versions of the specification.
- Deferred to a later version. The comment is considered to be a real
- issue but one that can be dealt with in a later version of the specification.
Version numbers
When a specification is proposed for inclusion, the owner specifies the final specification version that they want to include in the release. Releases between that point and the final release are identified by suffixing that release. This is best demonstrated by an example:
1.0 Draft 1* 1.0 Draft 2* 1.0 Beta 1* (specification enters Beta phase) 1.0 Beta 2* 1.0 Candidate 1* (specification enters Candidate phase) 1.0*
(Question: this versioning would be very annoying for packages, because the version numbers don't numerically compare. Is this a problem for specifications?)
-- Main.OwenTaylor - 19 Jul 2004