Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v750)
In-Reply-To: <9C07A10D-4DD5-490F-802F-075BE1D2105B@visi.com>
References: <448C6A63.8010306@hogstrom.org> <448CB880.1080407@toolazydogs.com>
 <74e15baa0606111755m53e30938kb2e12bc70b4772aa@mail.gmail.com>
 <448CC011.4090901@toolazydogs.com>
 <9C07A10D-4DD5-490F-802F-075BE1D2105B@visi.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B8E5AF53-E08F-4770-9EB4-93C734E4B7B8@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Thoughts about what a release is
Date: Mon, 12 Jun 2006 11:53:33 -0700
To: dev@geronimo.apache.org

On Jun 12, 2006, at 11:46 AM, David Blevins wrote:

> On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote:
>
>> Features would not get scheduled in until someone actually commits  
>> to doing that feature.
>
> I like this approach for most things.  There will always be the  
> need to say "x needs to be fixed to ship this release" even if no  
> one is signed up to work on it.  I just wish we'd vote or come to a  
> consensus on items like these *before* they get assigned to a  
> release.  IMHO, having to +1 it to be added to the release means  
> among many things you 1) saw it, 2) know about it, 3) are fully  
> aware of what is outstanding and not yet being worked on, and 4)  
> you agree with it.
>
> I'm fine voting on blocks of related issues all at once to speed up  
> the process.
>
> I think having to agree before hand on what goes in and what's  
> required for a release will force us to talk about things earlier  
> in the release cycle rather than later.

Cool idea.  I think we should try it out.

+1 to vote on scheduling a feature in a release

-dain