Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
I forgot to vote. Doh. +1 Accept +1 create app subproject and move apps, samples to it geir On Sep 20, 2005, at 12:13 PM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[RESULT] Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
Accept DayTrader : +1 from geir, dain, joe, alan, david, sachin, dims, john, gianny, david So let it be noted that the DayTrader contribution was accepted. For the App subproject : +1 from geir, joe, dims -1 from everyone else So noted that this isn't happening now. geir On Sep 20, 2005, at 12:13 PM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
[EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 Day trader will evolve over time to incorporate new standards (J2EE 5.0) and will also be expanded to incorporate different non-J2EE features (Hibernate is one option). Regardless of where it is Day trader needs to have a specific release so performance comparisons will have some relevance. At a minimum we should probably release the EAR and deployment plans with Geronimo for given Milestones / releases so there is a stable reference for the release. I suggest we incorporate the source code with the ear so that becomes the reference source as well. David's point is spot on as the deployment plans and other factors affect Day Trader so that is an issue. I think if we start it off with Geronimo makes sense and we course correct if we need to. Matt Geir Magnusson Jr. wrote: On Sep 21, 2005, at 12:13 AM, David Jencks wrote: My concern is primarily with the geronimo plan. While presumably the app itself isn't going to need to change to be deployed to other app servers, I expect each server to need a separate plan. Wouldn't that be part of the DayTrader project to maintain, since they know what they need to deploy, and that may change over time? I was thinking we'd keep the app and geronimo plan together in synch with the geronimo version. Obviously this is not ideal, but I haven't thought of a better solution. Maybe have the app separate and a module in geronimo/apps to build a configuration for the current geronimo version? Or just force the people working on DayTrader to follow, or stablize our plan :) I see what you're saying. (My biggest concern with asking the question was to see if it was because people had different ideas about how heavy a subproject was.) geir thanks david jencks On Sep 20, 2005, at 11:59 PM, Geir Magnusson Jr. wrote: I'm just curious what people expect to happen here.I'm happy to go with the flow, but at least want to understand the flow. DayTrader is an application that is used as a performance tool for any J2EE server, so it's not Geronimo only. (Contrast that with the console, as an example.) It makes little sense to me to tie it to Geronimo releases no matter what the stability of Geronimo. We can use it to measure Geronimo against other servers, and should use it daily to ensure that we don't regress performance- wise. To do that, I think we'd want to have a released version of it, so we could at compare apples to apples. The tools can't vary freely and randomly with the code we're trying to test Matt would have a better perspective, I guess. Instead of a new subproject, which people seem to find a bad idea for reasons I don't grok - as it's just out of SVN trunk, has separate release cycles from G server, and has some mention on the website - how about at least putting it into devtools? Can we avoid adding to the clutter of trunk, something we seemed to support earlier today? geir On Sep 20, 2005, at 8:48 PM, David Blevins wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. On Sep 20, 2005, at 4:28 PM, John Sisson wrote: (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle) Well put. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
Yup, that is part of the cleanup effort :) Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. I think I'm a bit confused here. You seem to be implying that if the code is at scm/geronimo/daytrader it is a subproject. I think it makes since to move the applications out of trunk to keep it clean, but I don't think that requires us to create an applications subproject. I getting the feeling that subproject is our new golden hammer (http://en.wikipedia.org/wiki/Golden_hammer), and creating a subproject with one person is a pretty good sign. I say let's not put the cart before the horse and when we get more people involved in applications we can take on the burden of adding subproject. -dain On Sep 20, 2005, at 9:13 AM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project - The more good samples we have will quicken and assist the adoption of Geronimo +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it. - One additional idea on this second vote: Do we really need another sub-project? In a very real sense samples are a developer tool. Not in the same way as an IDE ... but they are certainly a developer aid. I would suggest that we move DayTrader and other samples to the devtools subproject. That could also be the location of other items that would be part of a developer toolkit such as migration utilities, developer documentation, or anything else that we would produce to assist developers building on Geronimo. Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
On Sep 20, 2005, at 12:28 PM, Dain Sundstrom wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. I think I'm a bit confused here. You seem to be implying that if the code is at scm/geronimo/daytrader it is a subproject. I was going to disagree, but after thinking for a sec, ... well, yes. To me only things that distinguish a subproject from main tree is that a) it's not in the main tree b) it has separate release cycles c) it has a subheading on the web site so there can be specific docs describing it There's not much more to it. There is nothing special about the people working on it. We all are working on it, effectively. I think it makes since to move the applications out of trunk to keep it clean, but I don't think that requires us to create an applications subproject. I getting the feeling that subproject is our new golden hammer (http://en.wikipedia.org/wiki/ Golden_hammer), and creating a subproject with one person is a pretty good sign. I say let's not put the cart before the horse and when we get more people involved in applications we can take on the burden of adding subproject. What do you see the burden as? Right now, we have the code hanging around, and I was just suggesting that we a) move it out of the main tree b) let it have separate release cycles c) let there be space on the website so it can be described, pointed to, etc Does this help? We can optionally add another project in JIRA so that the release numbers don't get confusing, like we did for tools, but that's just because components in JIRA can't have separate versions and releases. geir -dain On Sep 20, 2005, at 9:13 AM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
On Sep 20, 2005, at 12:32 PM, Joe Bohn wrote: +1 Accept the DayTrader donation into the project - The more good samples we have will quicken and assist the adoption of Geronimo +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it. - One additional idea on this second vote: Do we really need another sub-project? In a very real sense samples are a developer tool. Not in the same way as an IDE ... but they are certainly a developer aid. I would suggest that we move DayTrader and other samples to the devtools subproject. That could also be the location of other items that would be part of a developer toolkit such as migration utilities, developer documentation, or anything else that we would produce to assist developers building on Geronimo. That would work for me, but we do have some sample apps, and they should probably follow, and then the purpose of devtools gets cluttered. I guess we can always separate later. I'm happy either way. I just want to make sure that people can find them if they are interested in working on them. geir Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Joe Bohn [EMAIL PROTECTED] He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Create an Applications subproject (to which Apache Geronimo There is no compelling need at the moment for this. Regards, Alan On 9/20/2005 9:32 AM, Joe Bohn wrote: +1 Accept the DayTrader donation into the project - The more good samples we have will quicken and assist the adoption of Geronimo +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it. - One additional idea on this second vote: Do we really need another sub-project? In a very real sense samples are a developer tool. Not in the same way as an IDE ... but they are certainly a developer aid. I would suggest that we move DayTrader and other samples to the devtools subproject. That could also be the location of other items that would be part of a developer toolkit such as migration utilities, developer documentation, or anything else that we would produce to assist developers building on Geronimo. I disagree. It's a sample application, not an actual developer tool. Regards, Alan
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. There are too many issues with regard to maintaining compatibility with multiple geronimo versions to consider decoupling the sample/application release cycle from geronimo's release cycle. thanks david jencks On Sep 20, 2005, at 12:13 PM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
On Sep 20, 2005, at 1:04 PM, David Jencks wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. There are too many issues with regard to maintaining compatibility with multiple geronimo versions to consider decoupling the sample/ application release cycle from geronimo's release cycle. How would that work then? Wouldn't you want daytrader to have multiple releases? thanks david jencks On Sep 20, 2005, at 12:13 PM, Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Create an Applications subproject (for now) Sachin. Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project - The more good samples we have will quicken and assist the adoption of Geronimo +1 Create an Applications subproject (or) DevTools. Doesn't matter to me. -- dims On 9/20/05, Sachin Patel [EMAIL PROTECTED] wrote: +1 Accept the DayTrader donation into the project -1 Create an Applications subproject (for now) Sachin. Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir --Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle). John Geir Magnusson Jr. wrote: There has been little comment or complaint about the DayTrader contribution GERONIMO-1016. I have done a cursory review and committed the code minus the binary code (.class and .ear) into trunk/sandbox. I did this as a courtesy to Matt so he can keep working and submitting patches for now. (Matt, get rid of the App.java stuff that seem to be maven detritus..) For efficiency, I'd like to vote on two things. First, whether or not to accept. All votes welcome, PMC votes binding : [ ] +1 Accept the DayTrader donation into the project [ ] -1 Do not accept DayTrader donation into the project Second, we now have a collection of samples, applications and such. I think that it would help keep the trunk clear if we started an Applications subproject (peer with DevTools) and move everything like it there. [ ] +1 Create an Applications subproject (to which Apache Geronimo subproject rules apply) and move DayTrader (if accepted) with other relevant codebases into it [ ] -1 Do not create Applications subproject. Leave in trunk. I'm happy for people to pose alternatives if there are good ones - I just didn't see any on the threads so far. geir
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
+1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. On Sep 20, 2005, at 4:28 PM, John Sisson wrote: (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle) Well put. -David
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
I'm just curious what people expect to happen here.I'm happy to go with the flow, but at least want to understand the flow. DayTrader is an application that is used as a performance tool for any J2EE server, so it's not Geronimo only. (Contrast that with the console, as an example.) It makes little sense to me to tie it to Geronimo releases no matter what the stability of Geronimo. We can use it to measure Geronimo against other servers, and should use it daily to ensure that we don't regress performance-wise. To do that, I think we'd want to have a released version of it, so we could at compare apples to apples. The tools can't vary freely and randomly with the code we're trying to test Matt would have a better perspective, I guess. Instead of a new subproject, which people seem to find a bad idea for reasons I don't grok - as it's just out of SVN trunk, has separate release cycles from G server, and has some mention on the website - how about at least putting it into devtools? Can we avoid adding to the clutter of trunk, something we seemed to support earlier today? geir On Sep 20, 2005, at 8:48 PM, David Blevins wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. On Sep 20, 2005, at 4:28 PM, John Sisson wrote: (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle) Well put. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
My concern is primarily with the geronimo plan. While presumably the app itself isn't going to need to change to be deployed to other app servers, I expect each server to need a separate plan. I was thinking we'd keep the app and geronimo plan together in synch with the geronimo version. Obviously this is not ideal, but I haven't thought of a better solution. Maybe have the app separate and a module in geronimo/apps to build a configuration for the current geronimo version? thanks david jencks On Sep 20, 2005, at 11:59 PM, Geir Magnusson Jr. wrote: I'm just curious what people expect to happen here.I'm happy to go with the flow, but at least want to understand the flow. DayTrader is an application that is used as a performance tool for any J2EE server, so it's not Geronimo only. (Contrast that with the console, as an example.) It makes little sense to me to tie it to Geronimo releases no matter what the stability of Geronimo. We can use it to measure Geronimo against other servers, and should use it daily to ensure that we don't regress performance-wise. To do that, I think we'd want to have a released version of it, so we could at compare apples to apples. The tools can't vary freely and randomly with the code we're trying to test Matt would have a better perspective, I guess. Instead of a new subproject, which people seem to find a bad idea for reasons I don't grok - as it's just out of SVN trunk, has separate release cycles from G server, and has some mention on the website - how about at least putting it into devtools? Can we avoid adding to the clutter of trunk, something we seemed to support earlier today? geir On Sep 20, 2005, at 8:48 PM, David Blevins wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. On Sep 20, 2005, at 4:28 PM, John Sisson wrote: (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle) Well put. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [vote] PMC to accept DayTrader contribution and/or/not create application subproject
On Sep 21, 2005, at 12:13 AM, David Jencks wrote: My concern is primarily with the geronimo plan. While presumably the app itself isn't going to need to change to be deployed to other app servers, I expect each server to need a separate plan. Wouldn't that be part of the DayTrader project to maintain, since they know what they need to deploy, and that may change over time? I was thinking we'd keep the app and geronimo plan together in synch with the geronimo version. Obviously this is not ideal, but I haven't thought of a better solution. Maybe have the app separate and a module in geronimo/apps to build a configuration for the current geronimo version? Or just force the people working on DayTrader to follow, or stablize our plan :) I see what you're saying. (My biggest concern with asking the question was to see if it was because people had different ideas about how heavy a subproject was.) geir thanks david jencks On Sep 20, 2005, at 11:59 PM, Geir Magnusson Jr. wrote: I'm just curious what people expect to happen here.I'm happy to go with the flow, but at least want to understand the flow. DayTrader is an application that is used as a performance tool for any J2EE server, so it's not Geronimo only. (Contrast that with the console, as an example.) It makes little sense to me to tie it to Geronimo releases no matter what the stability of Geronimo. We can use it to measure Geronimo against other servers, and should use it daily to ensure that we don't regress performance- wise. To do that, I think we'd want to have a released version of it, so we could at compare apples to apples. The tools can't vary freely and randomly with the code we're trying to test Matt would have a better perspective, I guess. Instead of a new subproject, which people seem to find a bad idea for reasons I don't grok - as it's just out of SVN trunk, has separate release cycles from G server, and has some mention on the website - how about at least putting it into devtools? Can we avoid adding to the clutter of trunk, something we seemed to support earlier today? geir On Sep 20, 2005, at 8:48 PM, David Blevins wrote: +1 Accept the DayTrader donation into the project -1 Do not create Applications subproject. Leave in trunk. On Sep 20, 2005, at 4:28 PM, John Sisson wrote: (Keep it simple for now. Review this later when Geronimo is more stable. I think it is too early to try to have applications with their own release cycle) Well put. -David -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
