geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 20:22:39 GMT
On Jun 12, 2006, at 12:15 PM, Alan D. Cabrera wrote:

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

Sure... seems you are making my point for me, am I missing something?

And to be clear, I am only talking about unassigned issues; things we  
as a group think should be done but don't yet have an owner.  I just  
want to see some discussion and agreement on these kinds of items.   
RTC is already in place for things actually done for a release.

I'd at least like to try it and see how it plays out.  We can drop it  
and go back to jira ping-pong or try something else if it doesn't  
work out well.

-David



Mime
View raw message