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: How about a quick 1.1.1?
Date Tue, 23 May 2006 22:29:11 GMT
* E254

Matt Hogstrom wrote:
> +1000
>
> Dain Sundstrom wrote:
>> How about we fix the actual show stoppers (only some of these 
>> blockers are show stoppers) and ship what we got?  Then we just do a 
>> dot release every few weeks as any additional things are fixed.  I 
>> think having more regular (short) releases will be positive for the 
>> community and will help to reduce our tendency to polish.  I know we 
>> all want to put out the best software but there is a point at which 
>> this desire starts to hurt us.
>>
>> -dain
>>
>> On May 23, 2006, at 9:33 AM, Matt Hogstrom wrote:
>>
>>> All,
>>>
>>> Here is what I would like to define as our closing set for 1.1
>>>
>>> * Restoration of Codehaus repos to get OEJB and TranQL up and running.
>>> * Complete testing of current performance fixes and commit them.
>>> * Close out SNAPSHOTs to final releases (depends partially on the 
>>> above)
>>> * Complete the following JIRAs
>>>
>>> Key    Priority    Summary
>>> GERONIMO-1492    Blocker    Many "org/apache/geronimo" configIds 
>>> still live in source tree
>>> GERONIMO-1849    Blocker    Attribute Manager broken WRT Reference
>>> GERONIMO-1860    Blocker    Tests of optional ConfigID components
>>> GERONIMO-1924    Blocker    Need to register the tomcat jndi url 
>>> handler somehow
>>> GERONIMO-1960    Blocker    Bad GBean reference isn't caught during 
>>> deployment
>>> GERONIMO-2006    Blocker    Deploying an application with an 
>>> incorrect deployment plan results in non-functional admin console panel
>>> GERONIMO-2038    Blocker    assemblies\minimal-tomcat-server fails 
>>> on windows due to file path length
>>> GERONIMO-2042    Blocker    ConfigurationAwareReference needs Serial 
>>> Version UID
>>> GERONIMO-2049    Blocker    Jetty HTTPS edit shows no keystores in list
>>> GERONIMO-2050    Blocker    Unlocking a trust store still prompts 
>>> for private key selection/password
>>> GERONIMO-2051    Blocker    Console Jetty HTTPS connector has wrong 
>>> trust store help text
>>> GERONIMO-2052    Blocker    Dynamically added keystores never appear 
>>> as unlocked
>>>
>>> * Ship Unstable build
>>>
>>> * Run CTS Testing
>>>
>>> * Let bake a few days for testing
>>>
>>> * Release 1.1
>>>
>>> This is how I'd like to finish this release.  Many of the above 
>>> defects are assigned to Aaron. Aaron, if you can keep the ones you 
>>> think you can handle over the next few days and unassign the rest.  
>>> Everyone else can grab a JIRA or two and get them fixed and closed 
>>> aggressively we can get this completed.
>>>
>>> Our original target for this release was April 28 and we're about a 
>>> month behind.  I would very much like to ship this by next Wednesday 
>>> (May 31) but perhaps Friday is more realistic.
>>>
>>> If you have some cycles all help is appreciated.
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> Aaron Mulder wrote:
>>>> OK.  I'm well aware that I've assigned a large number of 1.1 issues to
>>>> myself.  Is there someone else I should assign them to?  And do you
>>>> have a list of the "other issues" that you feel need to be addressed
>>>> for the 1.1 release?
>>>> Thanks,
>>>>    Aaron
>>>> On 5/23/06, Matt Hogstrom <matt@hogstrom.org> wrote:
>>>>> I appreciate your concerns but as you noted there are a number of 
>>>>> other bug fixes and blockers that
>>>>> *you* moved into the 1.1 stream that need to be addressed.  Null 
>>>>> pointer exceptions, etc.  If we
>>>>> were in better shape on the usability front I would agree with 
>>>>> you.  There are so many of those I
>>>>> think focusing on fixing what we know is broken is the priority.
>>>>>
>>>>> -1 on new features unless the other issues are addressed.  I've 
>>>>> been overly flexible on the release
>>>>> so far.  The release is going out this week or next.
>>>>>
>>>>> Thanks for your concern for the plugins but as release manager 
>>>>> that is not my priority.  A stable
>>>>> working release is.
>>>>>
>>>>> Matt
>>>>>
>>>>> Aaron Mulder wrote:
>>>>> > I don't agree.  1.1 is not yet out the door, and if anything, it

>>>>> looks
>>>>> > like 1.2 will take longer than anticipated.  Minor changes, 
>>>>> necessary,
>>>>> > I vote 1.1.  Remember, this change takes pressure off since 
>>>>> we'll be
>>>>> > able to release more features as plugins.  I'm strongly in favor
of
>>>>> > taking things out of the critical path, whereas deferring to 1.2

>>>>> will
>>>>> > extend the critical path by another 3+ months.
>>>>> >
>>>>> > Thanks,
>>>>> >    Aaron
>>>>> >
>>>>> > On 5/22/06, Matt Hogstrom <matt@hogstrom.org> wrote:
>>>>> >> I agree that they are necessary.  Let's put them in 1.2.  1.1
is
>>>>> >> almost out the door and adding new
>>>>> >> features at this point is very late in the game.  We're 
>>>>> currently 30
>>>>> >> days past our original date and
>>>>> >> almost 5 months past the 1.0 release.
>>>>> >>
>>>>> >> Please defer these till 1.2.
>>>>> >>
>>>>> >> Matt
>>>>> >>
>>>>> >> Aaron Mulder wrote:
>>>>> >> > We can call them what we want, but I think all the features
are
>>>>> >> > necessary, in particular in order to support plugins. 
The 
>>>>> advantage
>>>>> >> > of adding the first two features is that they let us take
a 
>>>>> lot of
>>>>> >> > other features *out* of the critical path, and release
them 
>>>>> as plugins
>>>>> >> > (also letting us support non-ASL licensed providers). 

>>>>> Basically, the
>>>>> >> > idea is to replace a properties file with a GBean, since
you 
>>>>> can't
>>>>> >> > effectively add to a properties file at plugin installation

>>>>> time, but
>>>>> >> > you can certainly add GBeans.  Bottom line, it's a small

>>>>> impact change
>>>>> >> > (console only, change the lookup logic that's already 
>>>>> encapsulated in
>>>>> >> > a helper class to do a GBean interface query instead of
a 
>>>>> properties
>>>>> >> > file load), and it has significant benefits (new JMS 
>>>>> providers or
>>>>> >> > security providers can be added at runtime via plugins
and do 
>>>>> not need
>>>>> >> > to be hardcoded into the Geronimo distribution).
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> >    Aaron
>>>>> >> >
>>>>> >> > On 5/22/06, Matt Hogstrom <matt@hogstrom.org> wrote:
>>>>> >> >> Based on the list below I think 1,2 and 3 are new function

>>>>> and 4 is a
>>>>> >> >> bug fix.
>>>>> >> >>
>>>>> >> >> Aaron Mulder wrote:
>>>>> >> >> > Here are the things that I still want to squeeze
into 1.1:
>>>>> >> >> > - fix console JMS to accept new providers at runtime
>>>>> >> >> > - fix console security realms to accept new providers
at 
>>>>> runtime
>>>>> >> >> > - add a missing Geronimo security provider to
console 
>>>>> security
>>>>> >> realms
>>>>> >> >> > - fix hot deploy dir so it notices files updated
while the 
>>>>> server
>>>>> >> was
>>>>> >> >> > down and deletes files if they are undeployed
some other way
>>>>> >> >> >
>>>>> >> >> > There are also AFAIK a number of not-yet-applied
patches 
>>>>> to review.
>>>>> >> >>
>>>>> >> >> Yes, there are several.
>>>>> >> >>
>>>>> >> >> I'm testing some performance related code.  I'm waiting
and 
>>>>> hoping
>>>>> >> >> Codehaus comes up soon :)
>>>>> >> >>
>>>>> >> >> >
>>>>> >> >> > Thanks,
>>>>> >> >> >    Aaron
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>
>>
>>
>>


Mime
View raw message