Re: JIRA-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
kelvin goodson wrote: Luciano, can you confirm in the JIRA whether the updated fix is good? I'll keep an eye on this thread to see how your plans develop, and what that might mean for SDO release plans. Kelvin. On 10/09/2007, Luciano Resende [EMAIL PROTECTED] wrote: We have found an issue on the SDO Tools, described in JIRA-1673 [1] that is affecting the proper generation of java interfaces from a given wsdl. What's the plan to get this fix, when available, in SCA 1.0 release ? This might require a new SDO release ? [1] http://issues.apache.org/jira/browse/TUSCANY-1673 I have checked in a workaround for this problem under revision r574423. We should leverage the SDO fix as soon as it's in an SDO release, but the workaround in place in r574423 will allow a Tuscany SCA 1.0 release to work with the published SDO 1.0 release. I can't comment on the SDO fix as I've just looked into the workaround, but Luciano probably can. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
We have found an issue on the SDO Tools, described in JIRA-1673 [1] that is affecting the proper generation of java interfaces from a given wsdl. What's the plan to get this fix, when available, in SCA 1.0 release ? This might require a new SDO release ? [1] http://issues.apache.org/jira/browse/TUSCANY-1673 On 9/3/07, Luciano Resende [EMAIL PROTECTED] wrote: Great, so looks like we would need a DAS release compatible with SDO 1.0 in order to include any SCA/DAS integration in the SCA 1.0 release. I'll try to get that done, by cutting a branch and working on a DAS release sometime this week. Please let me know if there is any changes in plan. On 8/28/07, kelvin goodson [EMAIL PROTECTED] wrote: There are no plans in place yet for the next SDO release. 1.0-incubating would seem the obvious choice. Kelvin. On 28/08/07, ant elder [EMAIL PROTECTED] wrote: That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
Great, so looks like we would need a DAS release compatible with SDO 1.0 in order to include any SCA/DAS integration in the SCA 1.0 release. I'll try to get that done, by cutting a branch and working on a DAS release sometime this week. Please let me know if there is any changes in plan. On 8/28/07, kelvin goodson [EMAIL PROTECTED] wrote: There are no plans in place yet for the next SDO release. 1.0-incubating would seem the obvious choice. Kelvin. On 28/08/07, ant elder [EMAIL PROTECTED] wrote: That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
There are no plans in place yet for the next SDO release. 1.0-incubating would seem the obvious choice. Kelvin. On 28/08/07, ant elder [EMAIL PROTECTED] wrote: That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
Cutting the branch around the 14th to give more time to get the release into shape sounds good. We always seems to run into lots of minor sample problems when we produce an RC and I would expect that we would use some of the time after cutting the branch to fix these up and polish the samples. I'm not sure what we would do about functional problems after the branch has been cut. For the 0.9x releases we have tended to defer many of these JIRAs to the next release. For 1.0, I would expect there to be a greater focus on making sure the function we deliver in this release is working correctly. So I could imagine a 1.0 RC respin to fix a JIRA in the branch for a functional problem that is serious from a user perspective. Is this in line with others' expectations? Simon Jean-Sebastien Delfino wrote: ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. +1 I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 Nice! I think we should all spend a little bit of time now to take look at the JIRAs that we ran into recently. I suggest the following: - target them for SCA-1.0 if you care about them - volunteer for them and assign to yourself if you really care about them :) - target them for SCA-next if you think they can be handled post 1.0 I'll go over the JIRAs I know enough about in the next 2 days. One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
On the question of differing JIRAs, I think it depends on the JIRA :) We have to be careful making too many changes in the branch as previously there's always been regressions due to changes. There's also the question of who does the work - just raising a JIRA doesn't get the problem fixed and with the time pressure of getting an RC out there's not so much the release manager can do with a whole lot of open JIRAs other than defer them. How about doing these two things: 1) after the branch is cut become more and more strict about not making changes as RCs are done 2) JIRAs raised as critical or blocking don't deferred without agreement from the raiser or ML discussion So that would mean something like: Make an RC1 by the 14th for review, not really expecting that to be the final 1.0 but having an RC to vote on makes reviewing easier. The branch would be cut a little before the 14th to get things ready. People raise JIRAs for issues they find while reviewing and ideally fix the problem in branch and trunk themselves, but otherwise general development and changes are kept to a minimum in the branch but still possible if absolutely required. Then by the 18th start vote/review for RC2 and from then be more strict about what changes go into the branch, non-trivial fixes are only moved from trunk to branch after some community review and permission of the RM. Non critical or blocking JIRAs get deferred, those blocking ones get discussed and fixed if a volunteer is found to fix them in a suitable time frame. That gives time for three or maybe even four RCs and IPMC voting and a release in September. ...ant On 8/28/07, Simon Nash [EMAIL PROTECTED] wrote: Cutting the branch around the 14th to give more time to get the release into shape sounds good. We always seems to run into lots of minor sample problems when we produce an RC and I would expect that we would use some of the time after cutting the branch to fix these up and polish the samples. I'm not sure what we would do about functional problems after the branch has been cut. For the 0.9x releases we have tended to defer many of these JIRAs to the next release. For 1.0, I would expect there to be a greater focus on making sure the function we deliver in this release is working correctly. So I could imagine a 1.0 RC respin to fix a JIRA in the branch for a functional problem that is serious from a user perspective. Is this in line with others' expectations? Simon Jean-Sebastien Delfino wrote: ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. +1 I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 Nice! I think we should all spend a little bit of time now to take look at the JIRAs that we ran into recently. I suggest the following: - target them for SCA-1.0 if you care about them - volunteer for them and assign to yourself if you really care about them :) - target them for SCA-next if you think they can be handled post 1.0 I'll go over the JIRAs I know enough about in the next 2 days. One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
This sounds pretty close to what I had in mind. But I'm concerned about cutting the branch before the 14th. IMO the 14th is the earliest possible date we could cut the branch that would allow us to get enough done in the trunk to put us in a position to move into this more controlled mode. Simon ant elder wrote: On the question of differing JIRAs, I think it depends on the JIRA :) We have to be careful making too many changes in the branch as previously there's always been regressions due to changes. There's also the question of who does the work - just raising a JIRA doesn't get the problem fixed and with the time pressure of getting an RC out there's not so much the release manager can do with a whole lot of open JIRAs other than defer them. How about doing these two things: 1) after the branch is cut become more and more strict about not making changes as RCs are done 2) JIRAs raised as critical or blocking don't deferred without agreement from the raiser or ML discussion So that would mean something like: Make an RC1 by the 14th for review, not really expecting that to be the final 1.0 but having an RC to vote on makes reviewing easier. The branch would be cut a little before the 14th to get things ready. People raise JIRAs for issues they find while reviewing and ideally fix the problem in branch and trunk themselves, but otherwise general development and changes are kept to a minimum in the branch but still possible if absolutely required. Then by the 18th start vote/review for RC2 and from then be more strict about what changes go into the branch, non-trivial fixes are only moved from trunk to branch after some community review and permission of the RM. Non critical or blocking JIRAs get deferred, those blocking ones get discussed and fixed if a volunteer is found to fix them in a suitable time frame. That gives time for three or maybe even four RCs and IPMC voting and a release in September. ...ant On 8/28/07, Simon Nash [EMAIL PROTECTED] wrote: Cutting the branch around the 14th to give more time to get the release into shape sounds good. We always seems to run into lots of minor sample problems when we produce an RC and I would expect that we would use some of the time after cutting the branch to fix these up and polish the samples. I'm not sure what we would do about functional problems after the branch has been cut. For the 0.9x releases we have tended to defer many of these JIRAs to the next release. For 1.0, I would expect there to be a greater focus on making sure the function we deliver in this release is working correctly. So I could imagine a 1.0 RC respin to fix a JIRA in the branch for a functional problem that is serious from a user perspective. Is this in line with others' expectations? Simon Jean-Sebastien Delfino wrote: ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. +1 I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 Nice! I think we should all spend a little bit of time now to take look at the JIRAs that we ran into recently. I suggest the following: - target them for SCA-1.0 if you care about them - volunteer for them and assign to yourself if you really care about them :) - target them for SCA-next if you think they can be handled post 1.0 I'll go over the JIRAs I know enough about in the next 2 days. One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
Taking the branch on the 14th and making an RC1 on the 14th is possible, just the RC is likely to be a little rough as there won't be much time at all to do checking. But as we're talking about RC1 not expected to be _the_ RC then i guess that could be fine. ...ant On 8/28/07, Simon Nash [EMAIL PROTECTED] wrote: This sounds pretty close to what I had in mind. But I'm concerned about cutting the branch before the 14th. IMO the 14th is the earliest possible date we could cut the branch that would allow us to get enough done in the trunk to put us in a position to move into this more controlled mode. Simon ant elder wrote: On the question of differing JIRAs, I think it depends on the JIRA :) We have to be careful making too many changes in the branch as previously there's always been regressions due to changes. There's also the question of who does the work - just raising a JIRA doesn't get the problem fixed and with the time pressure of getting an RC out there's not so much the release manager can do with a whole lot of open JIRAs other than defer them. How about doing these two things: 1) after the branch is cut become more and more strict about not making changes as RCs are done 2) JIRAs raised as critical or blocking don't deferred without agreement from the raiser or ML discussion So that would mean something like: Make an RC1 by the 14th for review, not really expecting that to be the final 1.0 but having an RC to vote on makes reviewing easier. The branch would be cut a little before the 14th to get things ready. People raise JIRAs for issues they find while reviewing and ideally fix the problem in branch and trunk themselves, but otherwise general development and changes are kept to a minimum in the branch but still possible if absolutely required. Then by the 18th start vote/review for RC2 and from then be more strict about what changes go into the branch, non-trivial fixes are only moved from trunk to branch after some community review and permission of the RM. Non critical or blocking JIRAs get deferred, those blocking ones get discussed and fixed if a volunteer is found to fix them in a suitable time frame. That gives time for three or maybe even four RCs and IPMC voting and a release in September. ...ant On 8/28/07, Simon Nash [EMAIL PROTECTED] wrote: Cutting the branch around the 14th to give more time to get the release into shape sounds good. We always seems to run into lots of minor sample problems when we produce an RC and I would expect that we would use some of the time after cutting the branch to fix these up and polish the samples. I'm not sure what we would do about functional problems after the branch has been cut. For the 0.9x releases we have tended to defer many of these JIRAs to the next release. For 1.0, I would expect there to be a greater focus on making sure the function we deliver in this release is working correctly. So I could imagine a 1.0 RC respin to fix a JIRA in the branch for a functional problem that is serious from a user perspective. Is this in line with others' expectations? Simon Jean-Sebastien Delfino wrote: ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. +1 I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 Nice! I think we should all spend a little bit of time now to take look at the JIRAs that we ran into recently. I suggest the following: - target them for SCA-1.0 if you care about them - volunteer for them and assign to yourself if you really care about them :) - target them for SCA-next if you think they can be handled post 1.0 I'll go over the JIRAs I know enough about in the next 2 days. One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues
SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon
Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0 in September. +1 I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 Nice! I think we should all spend a little bit of time now to take look at the JIRAs that we ran into recently. I suggest the following: - target them for SCA-1.0 if you care about them - volunteer for them and assign to yourself if you really care about them :) - target them for SCA-next if you think they can be handled post 1.0 I'll go over the JIRAs I know enough about in the next 2 days. One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
