geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 18:46:43 GMT

On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote:

> Aaron Mulder wrote:
>> I'd feel a lot better about tight restrictions on 1.1.1 if we really
>> made 1.2 a "minor release" and put all the stuff on the plate for 1.2
>> into 2.0.  But so long as 1.2 is a major release, then 1.1.1 needs
>> more than hot fixes.  On a related point, I'm not sure we want
>> multiple big version releases per year.
> I agree with you here.  The nice thing about the policy that I  
> outlined below is that we can safely time box patch releases.
> As for what gets scheduled for what release, I think that it's not  
> realistic to start by stacking a release w/ issues and hope that  
> people will "show up" to get them done in the scheduled time frame;  
> this only works if we are making shoes ;).  With that said, time  
> boxing is what would work best with our unique body of developers.
> Working within the strict interpretation of releases that I  
> outlined below, people would schedule themselves in with concrete  
> commitments.
> Bugs would not get scheduled in until someone actually picked it up  
> and started working on it.  At that time, the developer would mark  
> what releases his changes would fix.
> 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.


View raw message