geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: How about a quick 1.1.1?
Date Tue, 23 May 2006 19:53:05 GMT
I like the idea, but think we need more discussion on it -

How long would we do 1.1.x releases - until 1.2 is released?

We would require each committer to update trunk as fixes were applied to 
1.1.x, right?

What criteria would be used to determine what could go into a 1.1.x vs. 
what should only go into trunk?
   - Could prereq version updates be made in 1.1.x?
   - Schema/plan changes would not be allowed in 1.1.x, right?
   - Configuration plans would be locked down (no splitting/renaming 
contents of configs\)?
   - Would we run CTS to verify nothing has been broken?


-Donald


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