You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/05/23 20:00:20 UTC
How about a quick 1.1.1?
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 <ma...@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 <ma...@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 <ma...@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
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>>
Re: How about a quick 1.1.1?
Posted by John Sisson <jr...@gmail.com>.
+1
John
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 <ma...@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 <ma...@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 <ma...@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
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>
>
Re: How about a quick 1.1.1?
Posted by Sachin Patel <sp...@gmail.com>.
+1
On May 23, 2006, at 2:00 PM, 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 <ma...@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 <ma...@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 <ma...@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
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>
-sachin
Re: How about a quick 1.1.1?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'll start a new thread on the 1.2 topic.
Donald Woods wrote:
> 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 <ma...@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 <ma...@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 <ma...@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
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>
>>
>>
Re: How about a quick 1.1.1?
Posted by Dain Sundstrom <da...@iq80.com>.
There are a lot of +1s here so I went ahead and added a 1.1.1 version
to jira. If we decide not to do a 1.1.1, we can always delete it.
-dain
On May 24, 2006, at 10:01 AM, Donald Woods wrote:
> +1 to a 1.1.1 release, if we follow the responses/guidelines from
> Dain and Matt below.
>
> -Donald
>
>
> Matt Hogstrom wrote:
>> Inline
>> Dain Sundstrom wrote:
>>> On May 23, 2006, at 12:53 PM, Donald Woods wrote:
>>>
>>>> I like the idea, but think we need more discussion on it -
>>>
>>>
>>> I think we need a compromise here. If we make it too
>>> restrictive, people won't work on "dot" releases and they will
>>> drag out the normal release cycle to polish their bits because
>>> they know it is there last chance. On the other side if we let
>>> anything in, our releases well be viewed with suspicion. I think
>>> the right tact to take here is to come up with some guidelines,
>>> where stuff like schema are not changed in backwards incompatible
>>> ways, and stuff like the web console can have larger changes.
>>>
>>> In the future, I'm hoping we can architect the server so fast
>>> moving code, like the console, can be released at a different
>>> schedule then say the transaction manager. On this specific,
>>> case a modular console would help :)
>>>
>>>> How long would we do 1.1.x releases - until 1.2 is released?
>>>
>>>
>>> I would say as long as people want to do them. Frankly, I would
>>> be surprised to see more that 2 of these, but if say Aaron ;) has
>>> the energy to do more...
>>>
>>>> We would require each committer to update trunk as fixes were
>>>> applied to 1.1.x, right?
>>>
>>>
>>> As long as the fix is still valid in trunk, absolutely.
>>>
>>>> What criteria would be used to determine what could go into a
>>>> 1.1.x vs. what should only go into trunk?
>>>
>>>
>>> I would say 1.1.1 is limited to bug fixes and usability issues.
>>> I would put fixing console, cli, and tooling into the usability
>>> bucket as long a the changes don't impact he mainline server code.
>>>
>>>> - Could prereq version updates be made in 1.1.x?
>>>
>>>
>>> I don't know what you mean.
>> If your referring to changing pre-reqs on other jars in terms of
>> dependencies I'd say this is an it depends case. changing pre-
>> reqs like Tomcat Versions and the like would have a direct impact
>> on whether a "version" was still certified or not.
>>>
>>>> - Schema/plan changes would not be allowed in 1.1.x, right?
>>>
>>>
>>> I would allow additive optional elements, which means that any
>>> 1.1.0 plan would work in 1.1.1+.
>>>
>> We'd need to be careful here in terms of how we end up doing
>> clustering and Administration. If we are expecting users to base
>> configurations off a template this may make items incompatible.
>> We'll also have to pay much closer attention to things that are
>> serialized.
>>>> - Configuration plans would be locked down (no splitting/
>>>> renaming contents of configs\)?
>>>
>>>
>>> Got me.
>>>
>>>> - Would we run CTS to verify nothing has been broken?
>>>
>>>
>>> I'd say why not, but I don't think we are required.
>>>
>> I don't think this is a requirement (especially if the changes are
>> bug fixes). I'd say this is optional in point releases and up to
>> the discretion of the developer making the change.
>>> -dain
>>>
>>>
>>>
Re: How about a quick 1.1.1?
Posted by Donald Woods <dr...@yahoo.com>.
+1 to a 1.1.1 release, if we follow the responses/guidelines from Dain
and Matt below.
-Donald
Matt Hogstrom wrote:
> Inline
>
> Dain Sundstrom wrote:
>
>> On May 23, 2006, at 12:53 PM, Donald Woods wrote:
>>
>>> I like the idea, but think we need more discussion on it -
>>
>>
>> I think we need a compromise here. If we make it too restrictive,
>> people won't work on "dot" releases and they will drag out the normal
>> release cycle to polish their bits because they know it is there last
>> chance. On the other side if we let anything in, our releases well be
>> viewed with suspicion. I think the right tact to take here is to come
>> up with some guidelines, where stuff like schema are not changed in
>> backwards incompatible ways, and stuff like the web console can have
>> larger changes.
>>
>> In the future, I'm hoping we can architect the server so fast moving
>> code, like the console, can be released at a different schedule then
>> say the transaction manager. On this specific, case a modular console
>> would help :)
>>
>>> How long would we do 1.1.x releases - until 1.2 is released?
>>
>>
>> I would say as long as people want to do them. Frankly, I would be
>> surprised to see more that 2 of these, but if say Aaron ;) has the
>> energy to do more...
>>
>>> We would require each committer to update trunk as fixes were applied
>>> to 1.1.x, right?
>>
>>
>> As long as the fix is still valid in trunk, absolutely.
>>
>>> What criteria would be used to determine what could go into a 1.1.x
>>> vs. what should only go into trunk?
>>
>>
>> I would say 1.1.1 is limited to bug fixes and usability issues. I
>> would put fixing console, cli, and tooling into the usability bucket
>> as long a the changes don't impact he mainline server code.
>>
>>> - Could prereq version updates be made in 1.1.x?
>>
>>
>> I don't know what you mean.
>
>
> If your referring to changing pre-reqs on other jars in terms of
> dependencies I'd say this is an it depends case. changing pre-reqs like
> Tomcat Versions and the like would have a direct impact on whether a
> "version" was still certified or not.
>
>>
>>> - Schema/plan changes would not be allowed in 1.1.x, right?
>>
>>
>> I would allow additive optional elements, which means that any 1.1.0
>> plan would work in 1.1.1+.
>>
>
> We'd need to be careful here in terms of how we end up doing clustering
> and Administration. If we are expecting users to base configurations
> off a template this may make items incompatible. We'll also have to pay
> much closer attention to things that are serialized.
>
>>> - Configuration plans would be locked down (no splitting/renaming
>>> contents of configs\)?
>>
>>
>> Got me.
>>
>>> - Would we run CTS to verify nothing has been broken?
>>
>>
>> I'd say why not, but I don't think we are required.
>>
> I don't think this is a requirement (especially if the changes are bug
> fixes). I'd say this is optional in point releases and up to the
> discretion of the developer making the change.
>
>> -dain
>>
>>
>>
>
>
Re: How about a quick 1.1.1?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Inline
Dain Sundstrom wrote:
> On May 23, 2006, at 12:53 PM, Donald Woods wrote:
>
>> I like the idea, but think we need more discussion on it -
>
> I think we need a compromise here. If we make it too restrictive,
> people won't work on "dot" releases and they will drag out the normal
> release cycle to polish their bits because they know it is there last
> chance. On the other side if we let anything in, our releases well be
> viewed with suspicion. I think the right tact to take here is to come
> up with some guidelines, where stuff like schema are not changed in
> backwards incompatible ways, and stuff like the web console can have
> larger changes.
>
> In the future, I'm hoping we can architect the server so fast moving
> code, like the console, can be released at a different schedule then say
> the transaction manager. On this specific, case a modular console would
> help :)
>
>> How long would we do 1.1.x releases - until 1.2 is released?
>
> I would say as long as people want to do them. Frankly, I would be
> surprised to see more that 2 of these, but if say Aaron ;) has the
> energy to do more...
>
>> We would require each committer to update trunk as fixes were applied
>> to 1.1.x, right?
>
> As long as the fix is still valid in trunk, absolutely.
>
>> What criteria would be used to determine what could go into a 1.1.x
>> vs. what should only go into trunk?
>
> I would say 1.1.1 is limited to bug fixes and usability issues. I would
> put fixing console, cli, and tooling into the usability bucket as long a
> the changes don't impact he mainline server code.
>
>> - Could prereq version updates be made in 1.1.x?
>
> I don't know what you mean.
If your referring to changing pre-reqs on other jars in terms of dependencies I'd say this is an it
depends case. changing pre-reqs like Tomcat Versions and the like would have a direct impact on
whether a "version" was still certified or not.
>
>> - Schema/plan changes would not be allowed in 1.1.x, right?
>
> I would allow additive optional elements, which means that any 1.1.0
> plan would work in 1.1.1+.
>
We'd need to be careful here in terms of how we end up doing clustering and Administration. If we
are expecting users to base configurations off a template this may make items incompatible. We'll
also have to pay much closer attention to things that are serialized.
>> - Configuration plans would be locked down (no splitting/renaming
>> contents of configs\)?
>
> Got me.
>
>> - Would we run CTS to verify nothing has been broken?
>
> I'd say why not, but I don't think we are required.
>
I don't think this is a requirement (especially if the changes are bug fixes). I'd say this is
optional in point releases and up to the discretion of the developer making the change.
> -dain
>
>
>
Re: How about a quick 1.1.1?
Posted by Dain Sundstrom <da...@iq80.com>.
On May 23, 2006, at 12:53 PM, Donald Woods wrote:
> I like the idea, but think we need more discussion on it -
I think we need a compromise here. If we make it too restrictive,
people won't work on "dot" releases and they will drag out the normal
release cycle to polish their bits because they know it is there last
chance. On the other side if we let anything in, our releases well
be viewed with suspicion. I think the right tact to take here is to
come up with some guidelines, where stuff like schema are not changed
in backwards incompatible ways, and stuff like the web console can
have larger changes.
In the future, I'm hoping we can architect the server so fast moving
code, like the console, can be released at a different schedule then
say the transaction manager. On this specific, case a modular
console would help :)
> How long would we do 1.1.x releases - until 1.2 is released?
I would say as long as people want to do them. Frankly, I would be
surprised to see more that 2 of these, but if say Aaron ;) has the
energy to do more...
> We would require each committer to update trunk as fixes were
> applied to 1.1.x, right?
As long as the fix is still valid in trunk, absolutely.
> What criteria would be used to determine what could go into a 1.1.x
> vs. what should only go into trunk?
I would say 1.1.1 is limited to bug fixes and usability issues. I
would put fixing console, cli, and tooling into the usability bucket
as long a the changes don't impact he mainline server code.
> - Could prereq version updates be made in 1.1.x?
I don't know what you mean.
> - Schema/plan changes would not be allowed in 1.1.x, right?
I would allow additive optional elements, which means that any 1.1.0
plan would work in 1.1.1+.
> - Configuration plans would be locked down (no splitting/renaming
> contents of configs\)?
Got me.
> - Would we run CTS to verify nothing has been broken?
I'd say why not, but I don't think we are required.
-dain
Re: How about a quick 1.1.1?
Posted by Donald Woods <dr...@yahoo.com>.
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 <ma...@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 <ma...@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 <ma...@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
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>
>
>
Re: How about a quick 1.1.1?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
* 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 <ma...@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 <ma...@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 <ma...@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
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>
>>
>>
>>
Re: How about a quick 1.1.1?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
On 5/23/06, Matt Hogstrom <ma...@hogstrom.org> 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 <ma...@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 <ma...@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 <ma...@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
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >>
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >
> >
> >
> >
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: How about a quick 1.1.1?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
+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 <ma...@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 <ma...@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 <ma...@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
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>>
>
>
>
>