httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: [proposed] 2.4 Maintenance SIG
Date Thu, 19 Jan 2017 21:33:46 GMT
On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski <> wrote:
> Here's the real issue, as I see it. If there have been "recent
> breakages" it is not due to the release process, but rather
> the *testing* process. That is, not enough people testing
> 2.4-HEAD until we actually get close to a release. The idea
> should be that 2.4-HEAD is ALWAYS in a releasable and "runnable"
> state, it being RTC after all.

The idea should be that  *** TRUNK *** is always in a "run-able" and
releasable state, not withstanding legitimate showstoppers and some
multi-developer coordination in sorting out platform or other quirks
which are interdependent. RTC/CTR is a red herring. It simply flags
whether a couple of reviews occur before commit, not whether that
code deserves further review, or is subject to future veto, or may be
subject to further revision.

trunk/ should not be treated with any less caution than branches/2.4.x/,
that's what feature development branches are for.


When to Commit a Change

Ideas must be review-then-commit; patches can be commit-then-review.
With a commit-then-review process, we trust that the developer doing
the commit has a high degree of confidence in the change. Doubtful
changes, new features, and large-scale overhauls need to be discussed
before being committed to a repository. Any change that affects the
semantics of arguments to configurable directives, significantly adds
to the runtime size of the program, or changes the semantics of an
existing API function must receive consensus approval on the mailing
list before being committed.

Each developer is responsible for notifying the mailing list and
adding an action item to STATUS when they have an idea for a new
feature or major change to propose for the product. The distributed
nature of the Apache project requires an advance notice of 48 hours in
order to properly review a major change -- consensus approval of
either the concept or a specific patch is required before the change
can be committed. Note that a member might veto the concept (with an
adequate explanation), but later rescind that veto if a specific patch
satisfies their objections. No advance notice is required to commit
singular bug fixes.

Related changes should be committed as a group, or very closely
together. Half-completed projects should not be committed unless doing
so is necessary to pass the baton to another developer who has agreed
to complete the project in short order. All code changes must be
successfully compiled on the developer's platform before being

The current source code tree should be capable of complete compilation
at all times. However, it is sometimes impossible for a developer on
one platform to avoid breaking some other platform when a change is
committed, particularly when completing the change requires access to
a special development tool on that other platform. If it is
anticipated that a given change will break some other platform, the
committer must indicate that in the commit log.

The committer is responsible for the quality of any third-party code
or documentation they commit to the repository. All software committed
to the repository must be covered by the Apache LICENSE or contain a
copyright and license that allows redistribution under the same
conditions as the Apache LICENSE.

A committed change must be reversed if it is vetoed by one of the
voting members and the veto conditions cannot be immediately satisfied
by the equivalent of a "bug fix" commit. The veto must be rescinded
before the change can be included in any public release.


When do I know if it is a good time to release?

Generally speaking, when some useful changes have been applied since
the last release and there are no showstoppers left to be resolved. It
is our convention to indicate showstoppers in the STATUS file in the
repository. A showstopper entry does not imply that a release cannot
be made -- it is more of an indication of current project consensus
and a reminder of what fixes are on the critical path. Each RM gets to
choose when to cut a release candidate based on the current content of
subversion. The entire PMC gets to decide whether or not that
candidate deserves to be released.

View raw message