geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 19:15:56 GMT
David Blevins wrote:
> 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.

We are a group of individuals who work on a voluntary basis.  Assigning 
issues to a release amounts to wishful thinking; just look at the 
version ping pong that Matt and Aaron play for our releases.

IMO, voting can easily be accomplished w/ Jira voting.

> I'm fine voting on blocks of related issues all at once to speed up 
> the process.
Not sure that's necessary if we use Jira voting.
> 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.

So would lobbying for votes for your favorite issues.


View raw message