Folks,
The maintainers have looked over my proposed Release Policy for Exim,
and are roughly happy with its outline so far. So, time for comment
by the wider exim-dev community, before presentation to exim-users: yes,
there are plenty of users on the -dev list who don't develop, but still.
Those who actually provide patches and feedback on code deserve our
support and a longer window for comment.
If wiki user "PhilPennock" is still in the bottom-right corner, then:
http://wiki.exim.org/EximReleasePolicyProposedDraft
is my proposal. The page revision history is at:
http://wiki.exim.org/EximReleasePolicyProposedDraft?action=info
and I'll include a plaintext dump below.
As will be clear if you read it, it's less a hard policy than a setting
out of "normal" expectations.
Since nobody else has spoken and I rushed 4.74 for the security issues,
my plan is to drive the 4.75 release. As part of this, I'm going to use
this release policy; if feedback means I change the policy, that can
happen too, while it's in use. This is the trial run, after all.
Once this has baked a little, it will move from the wiki into The Exim
Specification.
The first two paragraphs excluded. :)
Regards,
-Phil
============================8< cut here >8==============================
Exim Release Policy
This is a proposal from one maintainer, not vetted or approved. It is provided
for consideration. It might become the consensus policy, or it might be
ridiculed into a hasty deletion. Just because something is stated here, that
does not mean it is an actual policy.
Some parts of this were decided at a meet-up of the maintainers in June 2010.
Who decides; enforceability
Exim is a volunteer project, with contributions from many people and
coordination from The Exim Maintainers, the people with commit access to the
main git repository. None of the maintainers are paid to provide public Exim
support, so nobody can commit to any form of "SLA" or guarantee. If we fail to
release according to this policy, that's just life.
If, in the best discretion of the people putting together a release, it is
necessary to diverge from this policy, even completely contradicting it, that
is entirely acceptable.
This policy lays down the expectations of what we plan to do in the normal or
predictable cases, if there is someone available with sufficient time to
shepherd a release. It is nothing more and is not a binding commitment.
Release triggers
* There is no fixed schedule for release.
* We aim for at least one release every six months, and if we have been idle
then we just release with what we have.
* If there is a bug-fix for a security-impacting problem, then:
+ We will obtain a CVE number
+ We will discuss with OS packagers the severity of the issue
+ If the problem permits privilege escalation from untrusted local users
to any user, it will warrant urgent release
+ If the problem permits remote code execution, this is considered
Critical and it will warrant urgent release and possibly the creation
of a branch, so that a release can be put out which contains *only*
this fix.
+ If the problem permits privilege escalation from the Exim run-time
user, then this is serious and will act as a trigger for a hurried
release, but will not on its own trigger a fire-drill. If there is also
a problem permitting untrusted local users to escalate privileges to
the Exim run-time user, or for remote code execution as the Exim
run-time user, then this becomes Critical.
* The "Release Engineer" or "Release Coordinator" shall simply be "whoever
steps forward".
Release numbering
* We will preserve lexical comparison of version numbers, so there will not
be a "4.9901" release or a "4.100" release. If we make it up to 4.99, then
the release following "4.99" will be "5.00".
* We may jump version numbers at our discretion, when considering the
features included.
* If we introduce backwards-incompatible changes, then the major number will
be increased. Eg, "5.23" followed by "6.00". But if we just reached 5.99,
then 6.00 will not be significant in this manner.
* There are no current plans for a grand rewrite.
Release verification
* All releases will be PGP signed. This includes all "tarballs" (code,
documentation) and the release announcement.
* The release announcement will include, within its text, cryptographic
checksums of our choosing. We reserve the right to switch algorithm.
* These releases will be performed by a PGP key belonging to an individual
maintainer. A shared, group, PGP key is deliberately not part of our trust
model.
* The PGP key will contain an identity ("uid") which includes the
maintainer's real name and an email address which is @exim.org
* PGP keys are identified by the uids and each has its own signatures in the
"Web of Trust". To be valid, the @exim.org uid will have been signed by a
group of the other Exim maintainers. In PGP speak, multiple maintainers
have keys "in the strong set", although the binding of the @exim.org might
not be. If another uid is more trusted by your client's trust paths, then
it is up to your discretion to decide whether or not you accept that name
as an Exim Maintainer.
Release Candidates & Buggy Releases
* Except in the most Critical emergencies, a release shall be preceded by at
least one "Release Candidate".
* Except when prompted by security issues, the intention to cut the first RC
shall have been announced ahead of time on the Exim Users mailing-list.
* More RCs are a matter of judgement for the person coordinating the release.
* Unless pushed by a security problem, there will be at least one week
between the first RC and the final release, with sufficient time to bake.
* People with commit on the master repository should not be committing new
features or major reworkings in the time between the first RC and the
actual release, to provide as stable and simple a set-up for the volunteer
performing a release.
* Problems to be addressed in this period shall include bugs of code or of
documentation, build issues, portability concerns and the like.
+ It's probably too late to address missing features
+ Uncommitted bug-fixes from Bugzilla are fair game for complaint
+ Sub-system maintainers whose bug-fixes have been overlooked should be
able to get those added ASAP and the Release Engineer should consider
then merging overlooked feature changes to the tree after the release.
* A Critical security problem may be issued as a minimal change against the
last stable release, as a "branch" in the code tree and the Release
Engineer may choose to entirely skip a public RC process in that scenario.
* We are dependent upon people testing the RCs to ensure platform
compatibility of the final release, across both OSes and component
versions.
+ Those who test RCs get to ensure that their platform is a first-class
supported platform for a release, and the final release should be
cleanly buildable and working on their platform.
+ We make no demands upon our users and do not expect RCs to be tested in
a production environment, but we do ask that people at least try to
compile and build the RC and send a test mail with it.
o This shouldn't be more than 30 minutes work total
o If you have a structured environment, with configurations in
revision history, the time consists of reading the release notes
(README.UPDATING, NewStuff and ChangeLog), adjusting your Local/
Makefile as needed and kicking off a build, then testing sending
mail with the new release.
o We greatly appreciate assistance from those with an environment
that lets them "canary" a change in production, and any feedback
from such testing is likely to receive the greatest attention from
the Release Engineer. But we do not consider this the typical
approach to testing RCs and accept this as a Very Nice Bonus,
should it happen.
+ Those who wait until a release is issued before testing will get such
support as we can offer; typically, patches will be written. We will
not rush to build a new release. OS packagers are experienced at
maintaining an extra patch for compatibility, and others with
significant issues should be attempting to track an RC.
+ If we push new releases as fast as possible to fix issues post-release,
that just encourages people to wait for a release before testing and
creates a burden for everyone else on every other platform, as a common
approach is to stay "up-to-date with releases, additional patches only
as needed" and multiple releases per month create undue burden.
+ The Release Engineer, as a volunteer, is not subject to demands that
they immediately do more work to satisfy people who did not themselves
put forward any effort until it was too late to help a release.
+ In the event of a release being problematic on some platform, we expect
to provide patches to those issues; we expect OS packagers are likely
to just use those patches; we will wait long enough for all the OS/
platform variants to shake loose any issues, before we get around to
cutting another release. This might be a couple of weeks. Since it is
expected that a security fix not thus be dependent upon the new release
happening, there should be a Release Candidate process on a normal
schedule for this follow-up release, to avoid cascading problems.
+ The follow-up release will not be constrained to be bug-fixes only
(unless the Release Engineer so chooses). Other committers shall be
free to commit feature patches or re-workings to the code-base at any
time after a release. A reward for trying RCs is that your feedback is
addressed in a stable environment where only bug-fixes are being
applied and you do not need to contend with some other new feature
causing headaches come the next release.
Conclusion
This policy tries to balance the volunteer effort, against the breadth of usage
and dependency upon Exim and the impact of releases. It provides incentives to
test Release Candidates and disincentives to leave testing until after a
Release. It establishes baseline expectations of what is "reasonable behaviour"
but does not establish any enforceable right.
While constructive, well-argued feedback is appreciated, if you are neither an
active contributor to the Exim community nor a packager for a major OS variant,
we shall not necessarily address your concerns. This policy is for us the
maintainers, to keep us from burn-out, to better serve the community of Exim
users.
Thank you for using Exim. Please work with us to improve it.
============================8< cut here >8==============================
