Hi, the calendar at http://www.boost.org/development/index.html has: 1.39.0 Closed for major code changes for today and: 1.39.0 Closed except by permission for next Friday, Apr 10th. I have a few questions: 1. Is this schedule still up-to-date? I did not notice any reminder emails. 2. I assume this refers to all commits to release branch? 3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk). 4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12. Thanks, Volodya
On Fri, Apr 3, 2009 at 10:14 AM, Vladimir Prus <ghost@cs.msu.su> wrote:
Hi,
the calendar at http://www.boost.org/development/index.html has:
1.39.0 Closed for major code changes
for today and:
1.39.0 Closed except by permission
for next Friday, Apr 10th. I have a few questions:
1. Is this schedule still up-to-date?
Yes.
I did not notice any reminder emails.
None have gone. I'll try to put out a notice later today.
2. I assume this refers to all commits to release branch?
The real concern is stability. Thus code changes are more of a concern than documentation.
3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk).
Have the changes been trouble free on trunk? Are the changes in areas with past history of changes causing unintended breakages? You are in the best position to judge.
4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12.
No problem. We've moved deadlines until after a weekend several times in the past. Thanks for checking, --Beman
Beman Dawes wrote:
I did not notice any reminder emails.
None have gone. I'll try to put out a notice later today.
Thanks.
2. I assume this refers to all commits to release branch?
The real concern is stability. Thus code changes are more of a concern than documentation.
3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk).
Have the changes been trouble free on trunk? Are the changes in areas with past history of changes causing unintended breakages? You are in the best position to judge.
I think most changes are safe, but still will try to do this wholesale merge this weekend, and then only merge specific fixes as necessary. (I also need to review/mark Boost.Build self-test, but that's another matter not directly related to building C++ Boost itself)
4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12.
No problem. We've moved deadlines until after a weekend several times in the past.
I guess it might be best to generally schedule deadlines for Mondays. Thanks, Volodya
Vladimir Prus wrote:
I think most changes are safe, but still will try to do this wholesale merge this weekend, and then only merge specific fixes as necessary. (I also need to review/mark Boost.Build self-test, but that's another matter not directly related to building C++ Boost itself)
I'm not sure if this is applicable, but here is what I do. a) On my local machine I create a BoostRelease directory downloaded from SVN release branch. b) For the directories related to my changes (boost/archive, boost/serialization, libs/serialization in my case, tools/build? in yours), I use the SVN "switch" command to change just these directories to the trunk where my changes have been running (and presumably passing). c) Then I run my tests on my local system. I only merge into the release when and if all my tests pass. This has a few really attractive benefits: a) It makes me very confident that merging my changes into the release branch will not result in any surprises. b) If some surprise occurs with my local tests, it's likely that this issue is mine alone and not some side effect of some issue in someone else's library. This avoids have to spend what can be a lot of time looking for something that I can't fix. Try it, you'll like it. Robert Ramey
Robert Ramey wrote:
Vladimir Prus wrote:
I think most changes are safe, but still will try to do this wholesale merge this weekend, and then only merge specific fixes as necessary. (I also need to review/mark Boost.Build self-test, but that's another matter not directly related to building C++ Boost itself)
I'm not sure if this is applicable, but here is what I do.
a) On my local machine I create a BoostRelease directory downloaded from SVN release branch.
b) For the directories related to my changes (boost/archive, boost/serialization, libs/serialization in my case, tools/build? in yours), I use the SVN "switch" command to change just these directories to the trunk where my changes have been running (and presumably passing).
c) Then I run my tests on my local system. I only merge into the release when and if all my tests pass.
This has a few really attractive benefits:
a) It makes me very confident that merging my changes into the release branch will not result in any surprises.
b) If some surprise occurs with my local tests, it's likely that this issue is mine alone and not some side effect of some issue in someone else's library. This avoids have to spend what can be a lot of time looking for something that I can't fix.
Try it, you'll like it.
Thanks. However, I don't think there's much point trying to teach me how to test things, for a multitude of reasons :-) - Volodya
participants (4)
-
Beman Dawes -
Robert Ramey -
Vladimir Prus -
Vladimir Prus