Re: Remaining 1.1 Issues
I think we should stay focused on the blocker JIRAs for now as our whittle point as discussed earlier in this thread. Other fixes that address functional issues are fine as well. Once those are complete other things could be considered. Right now the significant blocking factor is Codehaus and the restoration of TranQL CVS. Aaron Mulder wrote: Yeah, all right, but what's the difference between a late-breaking fix and a late-breaking feature of comparable size? Anything late-breaking is risky, but we now have the policy that 4 people will review it, plus we have a week to review the build before it becomes final, so what's the big deal? As much as I depress Alan, I don't think there's any point in griping about what goes where and when if we haven't decided what the cut-offs are going to be... If we said May 10, no more features, May 24 no more non-blocker bug fixes, fine. Except then if you want to put a non-blocker bug fix in on May 23, that's totally OK. In the future, let's make that kind of decision instead of the fuzzier "I kind of feel uncomfortable with the idea" as the build approaches. I'll carry on in another thread. :) Thanks, Aaron On 5/24/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: Not a "vote" in any way, but experience has shown (in various other projects) that those "last minute" additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
Yeah, all right, but what's the difference between a late-breaking fix and a late-breaking feature of comparable size? Anything late-breaking is risky, but we now have the policy that 4 people will review it, plus we have a week to review the build before it becomes final, so what's the big deal? As much as I depress Alan, I don't think there's any point in griping about what goes where and when if we haven't decided what the cut-offs are going to be... If we said May 10, no more features, May 24 no more non-blocker bug fixes, fine. Except then if you want to put a non-blocker bug fix in on May 23, that's totally OK. In the future, let's make that kind of decision instead of the fuzzier "I kind of feel uncomfortable with the idea" as the build approaches. I'll carry on in another thread. :) Thanks, Aaron On 5/24/06, Jim Jagielski <[EMAIL PROTECTED]> wrote: Not a "vote" in any way, but experience has shown (in various other projects) that those "last minute" additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
Not a "vote" in any way, but experience has shown (in various other projects) that those "last minute" additions almost invariably cause problems :) On May 23, 2006, at 1:43 AM, 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
+0 #2 Matt Hogstrom wrote: +1 #2 Dain Sundstrom wrote: So what alan is point out is I just suggested we add one more feature. I agree that this is another feature, so what do we want to do? I think we have three choices: 1) My idea below, isolate the broken porlets to an "experimental" section 2) Just remove the broken portlets 3) Fix the broken portlets I'm +1 on option 1 or 2. I don't care which option we choose. -dain On May 23, 2006, at 3:14 PM, Alan D. Cabrera wrote: /me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron
Re: Remaining 1.1 Issues
+1 #2 Dain Sundstrom wrote: So what alan is point out is I just suggested we add one more feature. I agree that this is another feature, so what do we want to do? I think we have three choices: 1) My idea below, isolate the broken porlets to an "experimental" section 2) Just remove the broken portlets 3) Fix the broken portlets I'm +1 on option 1 or 2. I don't care which option we choose. -dain On May 23, 2006, at 3:14 PM, Alan D. Cabrera wrote: /me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron
Re: Remaining 1.1 Issues
+1 for #2 On May 23, 2006, at 8:04 PM, Dain Sundstrom wrote: So what alan is point out is I just suggested we add one more feature. I agree that this is another feature, so what do we want to do? I think we have three choices: 1) My idea below, isolate the broken porlets to an "experimental" section 2) Just remove the broken portlets 3) Fix the broken portlets I'm +1 on option 1 or 2. I don't care which option we choose. -dain On May 23, 2006, at 3:14 PM, Alan D. Cabrera wrote: /me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron -sachin
Re: Remaining 1.1 Issues
So what alan is point out is I just suggested we add one more feature. I agree that this is another feature, so what do we want to do? I think we have three choices: 1) My idea below, isolate the broken porlets to an "experimental" section 2) Just remove the broken portlets 3) Fix the broken portlets I'm +1 on option 1 or 2. I don't care which option we choose. -dain On May 23, 2006, at 3:14 PM, Alan D. Cabrera wrote: /me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron
Re: Remaining 1.1 Issues
/me mumbles something about roses... Regards, Alan Dain Sundstrom wrote: How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron
Re: Remaining 1.1 Issues
How about we create an "experimental" section of the console menu, that only displays if you click the "show experimental" link (I'd guess it can all be done with java script on the browser side). I remember for 1.0 we removed a lot of portlets, but I think it would be ok to include most of them as long as we set the expectation that they are not finished works. -dain On May 22, 2006, at 8:14 AM, 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. Thanks, Aaron
Re: Remaining 1.1 Issues
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 PrioritySummary 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
Re: Remaining 1.1 Issues
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
Matt Hogstrom 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 :) I think that I will give some heads up: I am also waiting for Codehaus to be back on line to apply an OpenEJB patch related to GERONIMO-1545 (infamous CASE WHEN ? THEN ? ELSE ). The patch does not break the tck. Thanks, Gianny Thanks, Aaron
Re: Remaining 1.1 Issues
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
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 <[EMAIL PROTECTED]> 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: Remaining 1.1 Issues
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: Remaining 1.1 Issues
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. Thanks, Aaron A lot of these seem like new features. I am only in favor of calling a rose a rose and have no opinion as to whether or not to squeeze it in other than to say that we must acknowledge that you are adding risk to the release schedule. Regards, Alan
