From dev-return-74793-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Fri Mar 2 19:41:49 2012 Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8A7139C22 for ; Fri, 2 Mar 2012 19:41:49 +0000 (UTC) Received: (qmail 71383 invoked by uid 500); 2 Mar 2012 19:41:48 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 71330 invoked by uid 500); 2 Mar 2012 19:41:48 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 71320 invoked by uid 99); 2 Mar 2012 19:41:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 19:41:48 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [188.40.99.202] (HELO eru.sfritsch.de) (188.40.99.202) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 19:41:41 +0000 Received: from [10.1.1.6] (helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.72) (envelope-from ) id 1S3YLv-0004RQ-5A for dev@httpd.apache.org; Fri, 02 Mar 2012 20:41:19 +0100 From: Stefan Fritsch To: dev@httpd.apache.org Subject: Re: [RFC] try to solidify feature adoption criteria Date: Fri, 2 Mar 2012 20:41:17 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203022041.18362.sf@sfritsch.de> X-Virus-Checked: Checked by ClamAV on apache.org On Thursday 01 March 2012, Jeff Trawick wrote: > On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick wrote: > > New features are a natural part of the software life-cycle, but > > they > > One obvious alternative is to simply document that new features of > any magnitude can be added to trunk at will by any committer. > Presence in a stable branch is subject to a level of documentation > considered acceptable to other committers. Merging new features > to an existing stable branch is subject to commit rules for that > branch. I would prefer rules that distinguish between adding a feature to trunk and including a feature in a stable release. Like: Committers may introduce new modules in trunk. Anyone can call for a vote to have the module removed, requiring a passed vote (i.e. three +1s) for removal. When a release comes near, anyone who doesn't think the module is release quality may call a vote. The module needs a passed vote for inclusion in the release. This way a module may mature in trunk. But if it doesn't due to lack of interest, it would still need people to actively support it in order for it to be released. > --/-- > > Or just drop the documentation requirement. > > --/-- > > Not writing down any group think on this invites future conflict.