On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski <j...@jagunet.com> 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. From; http://httpd.apache.org/dev/guidelines.html 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 committed. 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. From; http://httpd.apache.org/dev/release.html 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.
