[1.37.0][date-time] Breaking the log jam
Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that. I've taken a look at a few of the proposed fixes. Without knowing anything about date-time, these seem like problems that really should have been fixed some time ago.The proposed patches I looked at seemed fine. So I think it is important we break the log jam. Proposal: * We give Andrey write permission. * He starts moving these fixes into trunk right away. * Anyone who cares about data-time watch the commits carefully, and discuss any issues with Andrey. * Once Andrey is satisfied with trunk test results, he asks permission to merge to release. * Unless there has been undue delay or issues have come up, we will give permission for this release. * I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release. Comments? --Beman
I agree with your plan. Is jeff at least available enough to approve this idea too? Sent from my iPhone On Oct 30, 2008, at 7:16 AM, Beman Dawes <bdawes@acm.org> wrote:
Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that.
I've taken a look at a few of the proposed fixes. Without knowing anything about date-time, these seem like problems that really should have been fixed some time ago.The proposed patches I looked at seemed fine. So I think it is important we break the log jam.
Proposal:
* We give Andrey write permission.
* He starts moving these fixes into trunk right away.
* Anyone who cares about data-time watch the commits carefully, and discuss any issues with Andrey.
* Once Andrey is satisfied with trunk test results, he asks permission to merge to release.
* Unless there has been undue delay or issues have come up, we will give permission for this release.
* I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release.
Comments?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I would disagree with this. Holding up release to include changes for one library that should have been done some time ago is exactly the situation which has created so much problem in the past. Doing this will prevent benefits of the current release-ready branch on all the other libraries from users who need them now. Release the current release-ready branch now. Get the 1.38.0 process going now and put the date-time updates into that. Robert Ramey Beman Dawes wrote:
Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that.
I've taken a look at a few of the proposed fixes. Without knowing anything about date-time, these seem like problems that really should have been fixed some time ago.The proposed patches I looked at seemed fine. So I think it is important we break the log jam.
Proposal:
* We give Andrey write permission.
* He starts moving these fixes into trunk right away.
* Anyone who cares about data-time watch the commits carefully, and discuss any issues with Andrey.
* Once Andrey is satisfied with trunk test results, he asks permission to merge to release.
* Unless there has been undue delay or issues have come up, we will give permission for this release.
* I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release.
Comments?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Thu Oct 30 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Beman Dawes wrote:
Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that.
<snip proposal>
* I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release.
Comments?
--Beman
I would disagree with this.
Holding up release to include changes for one library that should have been done some time ago is exactly the situation which has created so much problem in the past. Doing this will prevent benefits of the current release-ready branch on all the other libraries from users who need them now.
Release the current release-ready branch now.
Get the 1.38.0 process going now and put the date-time updates into that.
Robert Ramey
I think I responded too quickly before, and I agree with Robert. Isn't that the whole point of a quarterly release cycle? As soon as 1.37.0 is released, I am going to open a point-release branch where Andrey can check those changes in. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Oct 30, 2008 at 2:28 PM, David Abrahams <dave@boostpro.com> wrote:
on Thu Oct 30 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Beman Dawes wrote:
Andrey Semashev has pulled together a number of patches to address backed-up date-time tickets. He has tested them on Linux and Windows. The arrangement was that Jeff Garland would look them over, but Jeff just isn't finding the time to do that.
<snip proposal>
* I'm willing to hold the release a few days; in aggregate this is an important set of overdue fixes to a major library so I'd like to see them go in this release.
Comments?
--Beman
I would disagree with this.
Holding up release to include changes for one library that should have been done some time ago is exactly the situation which has created so much problem in the past. Doing this will prevent benefits of the current release-ready branch on all the other libraries from users who need them now.
Release the current release-ready branch now.
Get the 1.38.0 process going now and put the date-time updates into that.
Robert Ramey
I think I responded too quickly before, and I agree with Robert. Isn't that the whole point of a quarterly release cycle?
Sure, but I was thinking only of a couple of days, not a major slip. As soon as 1.37.0 is released, I am going to open a point-release branch
where Andrey can check those changes in.
Hum... So are you going to manage a point-release? That would change my thinking a bit. --Beman
Beman Dawes wrote:
Get the 1.38.0 process going now and put the date-time updates into that.
Robert Ramey
I think I responded too quickly before, and I agree with Robert. Isn't that the whole point of a quarterly release cycle?
Sure, but I was thinking only of a couple of days, not a major slip.
Suppose this turns into 10 days of testing merging etc. Then, a whole new beta round? And by that time, someone will find "just one more thing". My view is that we can't atain perfection. But we can achieve a product which shows strict improvement on a TIMELY basis.
As soon as 1.37.0 is released, I am going to open a point-release branch
where Andrey can check those changes in.
Hum... So are you going to manage a point-release? That would change my thinking a bit.
I would hope that it one could just start checking this stuff into the the trunk right now - and of course start testing it. This would give it some time in the trunk for testing and have it ready to be merged in to the next release ready branch after 1.37 is tagged. This could then be tagged as the 1.37.1 "point release" if that was considered necessary. Hopefully this would be pretty painless. Robert Ramey
On Thu, Oct 30, 2008 at 4:16 PM, Robert Ramey <ramey@rrsd.com> wrote:
Suppose this turns into 10 days of testing merging etc. Then, a whole new beta round? And by that time, someone will find "just one more thing". My view is that we can't atain perfection. But we can achieve a product which shows strict improvement on a TIMELY basis.
Why a whole new beta round? Isn't it: 1. Prepare beta 2. Identify problems in beta 3. Fix issues that won't hugely affect scheduled release date 4. Verify fixes didn't add regressions 5. Package release ? If step 3 isn't going to get done, you may as well just skip steps 1 and 2 as well. If step 3 is consistently impossible to get done, then you need a longer beta period.
I would hope that it one could just start checking this stuff into the the trunk right now - and of course start testing it. This would give it some time in the trunk for testing and have it ready to be merged in to the next release ready branch after 1.37 is tagged. This could then be tagged as the 1.37.1 "point release" if that was considered necessary. Hopefully this would be pretty painless.
I really hope point releases are considered. --Michael Fawcett
Is it possible to encapsulate OpenGL and send it to this for evaluation? _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!55...
Is it possible to encapsulate OpenGL and send it to this for evaluation?
Yes. Read this if you want to contribute: http://www.boost.org/development/submissions.html http://www.boost.org/development/requirements.html
Hum... So are you going to manage a point-release? That would change my thinking a bit.
BTW- its seems to me that you are on track to meet your goal as release manager to ship a release on the exact date it was originally promised. And better yet this will have been achieved with much less drama and personal hardship which previous (late) releases have required. To my mind, in the context of boost, this is an unprecedented and stunning achievment. Robert Ramey
on Thu Oct 30 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Hum... So are you going to manage a point-release? That would change my thinking a bit.
BTW- its seems to me that you are on track to meet your goal as release manager to ship a release on the exact date it was originally promised. And better yet this will have been achieved with much less drama and personal hardship which previous (late) releases have required. To my mind, in the context of boost, this is an unprecedented and stunning achievment.
I wholeheartedly agree with Robert. It would be a shame to undermine this achievement by breaking our own rules for what can be checked in when. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Thu Oct 30 2008, "Beman Dawes" <bdawes-AT-acm.org> wrote:
Hum... So are you going to manage a point-release? That would change my thinking a bit.
No, I'm not committing to doing that. However, as you, Doug Gregor, and I agreed in San Francisco, there should be a branch of every release available for checking in critical bugfixes, so a user can get the updates by checking out from svn. It's not a point release, but it's far better than a collection of hotfix patches. Anyone who wants to selectively revert (or apply) fixes in the point release branch can do so easily with svn. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Thu Oct 30 2008, "Beman Dawes" <bdawes-AT-acm.org> wrote:
Hum... So are you going to manage a point-release? That would change my thinking a bit.
No, I'm not committing to doing that. However, as you, Doug Gregor, and I agreed in San Francisco, there should be a branch of every release available for checking in critical bugfixes, so a user can get the updates by checking out from svn. It's not a point release, but it's far better than a collection of hotfix patches. Anyone who wants to selectively revert (or apply) fixes in the point release branch can do so easily with svn.
It's a shame to admit, but I think we missed the 1.37 train with these updates. I doubt we'll manage to walk through the full procedure of merging into the release branch until the release. So, IMHO, the best choice we have now is what David suggests. However, I'm still concerned about the point release branch status. IIUC, it is not tested regularly and can theoretically be broken. I'm also aware that some organizations don't fully trust software checked out from SVN just as they do trust official releases. So point releases are still wanted. Anyway, I will be fine with either decision, if it results in fixing those problems in DateTime. PS: Are there any pointers on the web page that will guide users how to obtain hotfixes and to checkout the point release branch for each release? I can only see general note on using SVN in the downloads section.
On Thu, Oct 30, 2008 at 5:17 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
It's a shame to admit, but I think we missed the 1.37 train with these updates. I doubt we'll manage to walk through the full procedure of merging into the release branch until the release. So, IMHO, the best choice we have now is what David suggests.
I'm inclined to agree, as Dave and Robert have made a strong case to not delay the release. It's late and I'm sinking. I'll try to post a reply to your questions tomorrow. --Beman
Here is a suggestion for anyone who wants to do a "point release" or "hot fix" which applies to just a specific library. a) Start out with a release tree on your development system b) Switch the directories you want to change to "trunk". For date-time I would guess this boost/date_time and libs/date_time. c) Make your changes and test them on your machine. d) Commit changes, will go into the trunk e) Wait a week to verify that trunk tests are OK f) Switch back to release for your directories g) Merge changes into release -ready. h) Wait a little bit to watch tests on release - ready branch. i) NOW - make a hot fix release. choose one of the following: 1) make a zip file with just boost/date_time and libs/date_time directories. 2) make a unified diff between the above two directories 3) for those who suffer from release manager envy i) makean SVN branch date_time 1.37 hot fix from the 1.37 tag ii) merge in changes on these two directories from release-ready branch ii) invoke procedure to create release on this branch. Name your "thing" 1.37 + date_time hot fix. Robert Ramey David Abrahams wrote:
on Thu Oct 30 2008, "Beman Dawes" <bdawes-AT-acm.org> wrote:
Hum... So are you going to manage a point-release? That would change my thinking a bit.
No, I'm not committing to doing that. However, as you, Doug Gregor, and I agreed in San Francisco, there should be a branch of every release available for checking in critical bugfixes, so a user can get the updates by checking out from svn. It's not a point release, but it's far better than a collection of hotfix patches. Anyone who wants to selectively revert (or apply) fixes in the point release branch can do so easily with svn.
participants (7)
-
Andrey Semashev -
Beman Dawes -
David Abrahams -
Kevin Sopp -
Michael Fawcett -
moh der -
Robert Ramey