Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Bruce Snyder wrote: On 7/20/05, Jeremy Boynes [EMAIL PROTECTED] wrote: Jeff Genender wrote: Ok...fair enough...then how far out would M5 be (estimates)? IMHO, waiting for the time between M3-M4 cannot be between M4- M5. If it is going to be that long, then +1000 to get it in now. If its a fairly short period, then waiting will not be a big deal. Blevins was talking about release early, often. Adding this change in can only delay M4 and as we are talking M5 in just a few weeks I would say stick with the current branch and use this as an incentive to get M5 out soon. I'd like to hear some opinions from community members who are not committers. If you are reading this message and you are not a committer, PLEASE SPEAK UP! We want to hear your opinion on this matter. Bruce In our projects we use tomcat as the web container of choice, so we'd be delighted with the new tomcat/jetty picker in geronimo. But, in the grand scheme of things I believe that getting a new milestone is more important right now, for various reasons (broken M3, TCK compliance, immense improvements all over). If M5 comes out in a month or so, then I guess everyone is going to be happy, even if the picker doesn't get in M4. In fact I would consider this an interesting goal for the project: learn how to release often. I would expect a milestone to take about a week to be released, after branching (for QA, TCK testing etc.). So I'd say take four weeks after M4 to bring in new stuff and fix bugs and then spend another week in QA, before releasing. If this schedule proves rather tight, next time increase the intervals by 25% or so. Perhaps, even appoint a release engineer to tag, branch, make the golden build and say no to new patches :-) As for poor old people like myself who would like a tomcat-integrated build rather sooner than later, perhaps we could beg Jeff to do an unsupported build with tomcat as default just once for M4? Regards, Panagiotis
Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
I think you need to add an option to the vote to distribute the same Tomcat/Jetty options we offered in M3. Namely: - Install Jetty only - Install with the install package, choose to install both Jetty and Tomcat. I'm not sure what happens to web apps you try to deploy, though surely we could figure it out. :) - Manually customize server plans (which is complex and you don't get the final plans in the binary), undeploy the J2EE server, and redeploy a new J2EE server minus Jetty plus Tomcat. Also, I think anyone who votes +1 for creating a new branch is committing to work on creating a new OpenEJB branch too and/or updating the OpenEJB branch to point to the new Geronimo branch (remember, +1 involves an implicit agreement to help!). It sounds like there will also be some TCK re-running involved too. Thanks, Aaron On Thu, 21 Jul 2005 [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Ok...fair enough...then how far out would M5 be (estimates)? IMHO, waiting for the time between M3-M4 cannot be between M4- M5. If it is going to be that long, then +1000 to get it in now. If its a fairly short period, then waiting will not be a big deal. I spent some good time last night with someone in IRC to ensure Tomcat was set up correctly for M4. I know its frustrating w/o the switcher...even for the guy who coded it ;-) I mess it up all the time too. Jeff Aaron Mulder wrote: I think you need to add an option to the vote to distribute the same Tomcat/Jetty options we offered in M3. Namely: - Install Jetty only - Install with the install package, choose to install both Jetty and Tomcat. I'm not sure what happens to web apps you try to deploy, though surely we could figure it out. :) - Manually customize server plans (which is complex and you don't get the final plans in the binary), undeploy the J2EE server, and redeploy a new J2EE server minus Jetty plus Tomcat. Also, I think anyone who votes +1 for creating a new branch is committing to work on creating a new OpenEJB branch too and/or updating the OpenEJB branch to point to the new Geronimo branch (remember, +1 involves an implicit agreement to help!). It sounds like there will also be some TCK re-running involved too. Thanks, Aaron On Thu, 21 Jul 2005 [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Jeff Genender wrote: Ok...fair enough...then how far out would M5 be (estimates)? IMHO, waiting for the time between M3-M4 cannot be between M4- M5. If it is going to be that long, then +1000 to get it in now. If its a fairly short period, then waiting will not be a big deal. Blevins was talking about release early, often. Adding this change in can only delay M4 and as we are talking M5 in just a few weeks I would say stick with the current branch and use this as an incentive to get M5 out soon. -- Jeremy
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
On 7/20/05, Jeremy Boynes [EMAIL PROTECTED] wrote: Jeff Genender wrote: Ok...fair enough...then how far out would M5 be (estimates)? IMHO, waiting for the time between M3-M4 cannot be between M4- M5. If it is going to be that long, then +1000 to get it in now. If its a fairly short period, then waiting will not be a big deal. Blevins was talking about release early, often. Adding this change in can only delay M4 and as we are talking M5 in just a few weeks I would say stick with the current branch and use this as an incentive to get M5 out soon. I'd like to hear some opinions from community members who are not committers. If you are reading this message and you are not a committer, PLEASE SPEAK UP! We want to hear your opinion on this matter. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
I am extremely strongly in favor of only bug fixes for M4 and putting out M5 in mid august and 1.0 in mid sept. I'd like to point out that re-branching at this point is essentially abandoning M4 for M5. I have committed substantial changes to head that are not yet necessarily completely stable and are also not quite complete. If we rebranch, we won't be able to get the new M4.5 out before mid august anyway. I abandoned my hopes of getting all the work I am putting in head into M4: after some consideration I decided that it was more important to get M4 out than my favorite features in, even though I was sure they would not be destabilizing. There's some difference in that my features have no discernable impact on the normal user, but still :-) thanks david jencks On Jul 20, 2005, at 6:56 AM, [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally.
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Ok...if we are in favor of an August M5, then I am cool with this. I want to point out a little history to understand why there is some passion in getting this into M4. My understanding about M(X), is the M stands for Milestone. I believe that you hit a milestone based on a set of criteria. I not only understood that we had concensus that this would be a part of milestone 4 and thus fit the criteria, but I was specifically asked by one of the committers on the project to get it done fast so it can be in M4. I worked very hard to get this out. It was somewhat disconcerting to me that this got kicked back to M5 after all of this...as I could have taken my time. I would only ask that A) M5 come in a relative short time period...and more importantly, that B) we decide ahead of time what is in the milestone, and cut based on the milestone roadmap's requirements of included options, as opposed by date. Although it would seem that A conflicts with B, it does not. If we keep our list relatively short, A will work with B. Finally, IMHO, there has been too much committer talk and decision on this subject. I really would love to hear what the community wants in M4 and M5. The community's voice should be the most important. Jeff David Jencks wrote: I am extremely strongly in favor of only bug fixes for M4 and putting out M5 in mid august and 1.0 in mid sept. I'd like to point out that re-branching at this point is essentially abandoning M4 for M5. I have committed substantial changes to head that are not yet necessarily completely stable and are also not quite complete. If we rebranch, we won't be able to get the new M4.5 out before mid august anyway. I abandoned my hopes of getting all the work I am putting in head into M4: after some consideration I decided that it was more important to get M4 out than my favorite features in, even though I was sure they would not be destabilizing. There's some difference in that my features have no discernable impact on the normal user, but still :-) thanks david jencks On Jul 20, 2005, at 6:56 AM, [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
This is a major major reason I think we have outgrown milestones. -David On Jul 20, 2005, at 10:31 AM, Jeff Genender wrote: Ok...if we are in favor of an August M5, then I am cool with this. I want to point out a little history to understand why there is some passion in getting this into M4. My understanding about M(X), is the M stands for Milestone. I believe that you hit a milestone based on a set of criteria. I not only understood that we had concensus that this would be a part of milestone 4 and thus fit the criteria, but I was specifically asked by one of the committers on the project to get it done fast so it can be in M4. I worked very hard to get this out. It was somewhat disconcerting to me that this got kicked back to M5 after all of this...as I could have taken my time. I would only ask that A) M5 come in a relative short time period...and more importantly, that B) we decide ahead of time what is in the milestone, and cut based on the milestone roadmap's requirements of included options, as opposed by date. Although it would seem that A conflicts with B, it does not. If we keep our list relatively short, A will work with B. Finally, IMHO, there has been too much committer talk and decision on this subject. I really would love to hear what the community wants in M4 and M5. The community's voice should be the most important. Jeff David Jencks wrote: I am extremely strongly in favor of only bug fixes for M4 and putting out M5 in mid august and 1.0 in mid sept. I'd like to point out that re-branching at this point is essentially abandoning M4 for M5. I have committed substantial changes to head that are not yet necessarily completely stable and are also not quite complete. If we rebranch, we won't be able to get the new M4.5 out before mid august anyway. I abandoned my hopes of getting all the work I am putting in head into M4: after some consideration I decided that it was more important to get M4 out than my favorite features in, even though I was sure they would not be destabilizing. There's some difference in that my features have no discernable impact on the normal user, but still :-) thanks david jencks On Jul 20, 2005, at 6:56 AM, [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds) on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread Wait or not? Respond quick. (M4 -- 24 hour notice of branch) on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread M4 Status, started by Aaron on 18th July, he said I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer. . Alan responded I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form. Alan then said I'm not opposed to the what and why. I am opposed to the how. David Jencks also agreed with Alan in the mail thread. So it seems that people are unhappy with the how as Alan said. Since it was already agreed that we are to have separate Tomcat and Jetty builds in M4, that decision should not be questioned and as a reminder Jeff's changes have the following benefits: * Less user problems - the previous method of having to edit many files is prone to failure, it caught me out many times, and I have seen others get caught out! * We don't have to document the M4 way of configuring the web containers and the M5 way of configuring. This makes the instructions more complicated and makes it harder for other forms of documentation to stay relevant (e.g. articles and Aaron's book). * Documentation does not have to be changed when we reach M5. * We are seen to be trying to minimise changes that impact configuration between releases. Looking back, it appears we branched too early. I propose that we vote on the how with the following options: a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA branch b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from HEAD when it is stable. John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s).
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
On the specific issue of Tomcat/Jetty picker I'm not sure that I follow all of the arguments for or against it. IMHO it isn't that large of an issue be it in M4 or M5. The only users affected would be those who require Tomcat and I don't imagine (although I could be wrong) that this is a large number. Also those who do require Tomcat are already accustomed to making the numerous changes so this won't be a "new pain point" if not delivered. I think the most important thing (as several folks have already mentioned) is to get M4 committed and out the door. We should take whatever path assures us that M4 will not be delayed. Regarding the discussion on milestone criteria ... I agree that we need to define the criteria ahead of time. However, there also needs to be a little bit of pragmatism in there too. If some function isn't ready in time we will have to make the call to either delay the delivery or deliver w/o the function. It really depends upon the impact to the users and the pain that is caused by either delaying a delivery or dropping a planned function. I think in general that the most important thing is to show regular, forward progress and a clear plan for the future. Jeff Genender wrote: Ok...if we are in favor of an August M5, then I am cool with this. I want to point out a little history to understand why there is some passion in getting this into M4. My understanding about M(X), is the M stands for Milestone. I believe that you hit a milestone based on a set of criteria. I not only understood that we had concensus that this would be a part of milestone 4 and thus fit the criteria, but I was specifically asked by one of the committers on the project to get it done fast so it can be in M4. I worked very hard to get this out. It was somewhat disconcerting to me that this got kicked back to M5 after all of this...as I could have taken my time. I would only ask that A) M5 come in a relative short time period...and more importantly, that B) we decide ahead of time what is in the milestone, and cut based on the milestone roadmap's requirements of included options, as opposed by date. Although it would seem that A conflicts with B, it does not. If we keep our list relatively short, A will work with B. Finally, IMHO, there has been too much committer talk and decision on this subject. I really would love to hear what the community wants in M4 and M5. The community's voice should be the most important. Jeff David Jencks wrote: I am extremely strongly in favor of only bug fixes for M4 and putting out M5 in mid august and 1.0 in mid sept. I'd like to point out that re-branching at this point is essentially abandoning M4 for M5. I have committed substantial changes to head that are not yet necessarily completely stable and are also not quite complete. If we rebranch, we won't be able to get the new M4.5 out before mid august anyway. I abandoned my hopes of getting all the work I am putting in head into M4: after some consideration I decided that it was more important to get M4 out than my favorite features in, even though I was sure they would not be destabilizing. There's some difference in that my features have no discernable impact on the normal user, but still :-) thanks david jencks On Jul 20, 2005, at 6:56 AM, [EMAIL PROTECTED] wrote: On the Geronimo IRC channel there was talk about the Tomcat/Jetty Picker not going in M4 because it is now involving more code changes than what people thought they had agreed to. This was a surprise to me and after discussion it was proposed that I call for a vote. Before I do, I thought a little background might be helpful.. Back in the mail thread "Preparation for M4 -- jetty vs tomcat or jetty and tomcat (two builds)" on 5th of July it was agreed that there would be a Tomcat and a Jetty build of Geronimo. In the mail thread "Wait or not? Respond quick. (M4 -- 24 hour notice of branch)" on 9th of July, it appears nobody asked to hold off creating the branch to do the work for the Tomcat / Jetty builds. Maybe it was just assumed it was going to be simple changes in the branch, or it was forgotten. In the mail thread "M4 Status", started by Aaron on 18th July, he said "I believe Jeff is working on separate plans for Tomcat and Jetty builds, so we can produce two separate distributions as people seemed to prefer." . Alan responded "I think that the notion that adding new features into a QA branch is a bad idea stands, regardless of how simple the changes are and how simple it is to merge them. It's simply bad form". Alan then said "I'm not opposed to the what and why. I am opposed to the how." David Jencks also agreed with Alan in the mail thread. So it seems that people are
Re: Disagreements regarding inclusion of Tomcat/Jetty Picker in M4 QA branch
Aaron Mulder wrote:
On Thu, 21 Jul 2005, Stefan Schmidt wrote:
3. Maybe I understand this wrong, but isn't it possible to offer two M4
binary versions (one with Jetty perconfigured, and one with Tomcat)? The
new feature in M5 will then be that the user decides during installation
(izpack) which config he wants, so we don't need two binary versions
anymore... Maybe I got this wrongly, but if I got this right then I
don't understand this discussion :-).
It is possible for someone to get it working through superhuman
effort. However, I don't think it's reasonable to require that anyone
who's working on testing the Tomcat build of M4 or packaging an M4 release
should go through that. Also, any two people who did will undoubtedly end
up with different results. Therefore, I don't think we should include a
Tomcat version of M4 based on the purely manual process.
What I meant was rather to just change the DD's and build the
modules/assembly again for (and then deliver this snapshot as binary) -
not to really separate the codebases as well ('superhuman effort'). This
way you would have one binary for Jetty and one for Tomcat (where the
only difference are the changed DD's - just like I did it yesterday
manually). Or did you refer to the commenting/uncommenting of the DD's
as 'superhuman effort'? :-)
IMHO, the biggest advantage to the change in HEAD is not that the
installer gives you more options, but that any developer can build Tomcat
with a simple command-line flag, which make it quite easy to work with and
test.
Aaron
