geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 23:45:55 GMT
David Blevins wrote:
> 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 am talking about those as well.  There's no point in assigning a 
version number to an unassigned issue if no one has committed to doing 
the work.  Maybe that's not what you're advocating.


Regards,
Alan



Mime
View raw message