based on some of the discussion so far, here's a semi-concrete,
semi-fragmentary proposal for how to govern releases and project
snapshots. this is my work alone, nobody asked me to do this, but it's
an attempt at a vaguely constructive entry into the current discussion
furball.
feel free to steal any or all of this for your own proposals.
overall goals:
encourage widespread release and testing of prototypes
require clear labelling of the origin of all releases
require community-wide rough consensus for a release attributed to the
community.
In the following, "Group" means a "community group", "Community"
refers to the entire Opensolaris community.
----
Project Releases:
Opensolaris projects are encouraged to release source and binary
snapshots for testing as frequently as resources permit to ensure that
people interested in a project can try its current state.
Test source and binary releases should clearly identify the project or
projects in control of the test release in file names, urls, etc.,
used for a distribution so that test releases are not mistaken for a
formal production-ready release.
Groups and Projects are ultimately responsible for defining their
own release criteria and approval process. As a baseline, using the
terms defined in section 8.4 of the the opensolaris constitution,
snapshot/test builds should happen via assumed approval; transition into
a period of nearly-final test releases (betas, release candidates,
etc.,) should have majority approval, while "final" releases should
happen by consensus. Changes from this baseline require Group
consensus.
Community Releases:
As an operating system, OpenSolaris involves the output of many Groups
and Projects. A release attributed to the Community as a whole must
involve the consensus and support of the Community as a whole.
The OGB has the power to charter a Project or other committee to
oversee a Community release. Prototype or test builds (clearly
identified as such) may be produced by the release committee as by any
other project.
As unanimity in a large group is nearly impossible to achieve, we
instead require well-documented rough consensus. A formal Community
release must be preceded by a public, non-anonymous poll of all Core
Contributors.
In advance of the poll, a release candidate shall be published.
(note: similarity to the IETF's IESG voting procedure is intentional)
Poll responses include:
1) Yes
This indicates that the Core Contributor has personally tested the
release candidate and believes it is ready to go.
2) No Objection
This indicates that the Core Contributor has no objection to the
release but has not personally tested the release candidate.
3) Not Ready: list of <bugid> (plus additional rationale).
One can not simply vote "No" without further explanation; one must
indicate specific defects that you believe must be fixed before the
release is ready.
---
After the polling period concludes, several things must happen:
- There must be at least <TBD-threshold-1> responses and
<TBD-threshold-2> Yes responses to the poll.
- The release committee must make a public response to each Not Ready
response.
- There must be consensus among the release committee after review of
objections that the release is ready.
Decisions by the release committee may be appealed to the OGB.
The release approval process shall be reviewed by the Community, and, if
necessary, amended through proposals to the OGB after each release.
-------
- Bill
