geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Thoughts about what a release is
Date Tue, 13 Jun 2006 04:06:24 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.
>

Based on our past experience over the last two releases and a couple of Milestones we all
feel the 
urgent need to get things fixed.  However, as I was clearing out 1.1 there were lots of assigned

issues with relatively low overhead in applying and verifying them but the assignee was busy
with 
other things.  This is fine.

IMHO JIRA's should not be assigned to a version number until there is someone that will be
working 
on them.  That way we'll end up with things people are planning on completing for a release
in the 
release.  We have had "important bugs" in JIRA (some older than two years).

In short, I think we should try it David.


> 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.
>

Yes, it will also have people think about what's important for the release.

One are we need to bone up on is making sure that we look at JIRAs when they come in.  There
are a 
number I moved to 1.1.1 and plan on integrating where people did the work and created a patch.
 It 
will help us grow the community a lot if they see we are attentive to their contributions
and that 
the contributions actually get in.  If the patch won't work, then we need to give them feedback
on 
what will work.  I think this is an ethic change for us.


> -David
> 
> 
> 
> 

Mime
View raw message