From dev-return-6896-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Tue Feb 05 00:24:16 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 7194 invoked from network); 5 Feb 2008 00:24:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Feb 2008 00:24:16 -0000 Received: (qmail 85472 invoked by uid 500); 5 Feb 2008 00:24:08 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 85458 invoked by uid 500); 5 Feb 2008 00:24:08 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 85443 invoked by uid 99); 5 Feb 2008 00:24:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2008 16:24:07 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.17] (HELO smtpout09.prod.mesa1.secureserver.net) (64.202.165.17) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 05 Feb 2008 00:23:37 +0000 Received: (qmail 30970 invoked from network); 5 Feb 2008 00:23:42 -0000 Received: from unknown (67.162.45.134) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 05 Feb 2008 00:23:42 -0000 Message-ID: <47A7AC8D.1020901@rowe-clan.net> Date: Mon, 04 Feb 2008 18:23:41 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: Convention for merge changelogs References: <47A79F8F.7080703@roguewave.com> In-Reply-To: <47A79F8F.7080703@roguewave.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Martin Sebor wrote: > > After Feature Freeze, our release process says that only the RM > does merges. Unless the RM wants to merge each change individually > the multi-change format is the only one that makes sense. Just want to point out or clarify a few things... multichange commits become much harder to follow, therefore they may be an obstacle to devs during a release vote. But either way, what you describe above is the process most ASF projects apply to one release. So let's say for a moment that Travis wants a release, and you want a release, and have different goals. Both branch, patch and tag, and the community votes on which release is right. It's a really obscure way to an end point (one release that the project agrees to), but it ensures a project's never hostage to only-one-way to get things done. It's an example of why a release can't be vetoed. But I want to clarify, no one individual ever has sole commit authority over a maintenance branch, period. I know this came up during incubation, but the policy is very harsh. The ASF is not about individual PMC members, not even the chairman, but it's a flat meritocracy. So the code is either C-T-R with every committer having direct-access, or R-T-C with every committer proposing patches, and a community vote (not one person's decision) over the patches that are applied. I'm a bit concerned, what with RW's generous test and build mechanics, etc, that the project does appear more homogeneous than even at the point it graduated (incubation is not the end of the diversity and broader community requirements). I've noticed about 3 or 4 posts a month which read as entirely partisan/commercial, and I'd appreciate if everyone would keep their eyes out for such problems. Bill