Permission to proceed?
Hello, Now that the beta has been out for a while, I'd like to proceed with my clean-up commits in trunk. I'd like to commit the patch in http://thread.gmane.org/gmane.comp.lib.boost.devel/244392/focus=244397 immediately and then proceed to remove the resulting dead code. Can I go ahead and do that? I assume that does not have any effect on the release branch. Thanks, Steve.
AMDG On 10/11/2013 02:33 PM, Stephen Kelly wrote:
Now that the beta has been out for a while, I'd like to proceed with my clean-up commits in trunk.
I'd like to commit the patch in
http://thread.gmane.org/gmane.comp.lib.boost.devel/244392/focus=244397
immediately and then proceed to remove the resulting dead code.
Can I go ahead and do that? I assume that does not have any effect on the release branch.
Commits to the trunk are always okay. Only the release branch gets frozen. In Christ, Steven Watanabe
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible. On Fri, Oct 11, 2013 at 4:48 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 10/11/2013 02:33 PM, Stephen Kelly wrote:
Now that the beta has been out for a while, I'd like to proceed with my clean-up commits in trunk.
I'd like to commit the patch in
http://thread.gmane.org/gmane.comp.lib.boost.devel/244392/focus=244397
immediately and then proceed to remove the resulting dead code.
Can I go ahead and do that? I assume that does not have any effect on the release branch.
Commits to the trunk are always okay. Only the release branch gets frozen.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 10/11/2013 11:49 PM, Rene Rivera wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible.
You mean 'high risk', not 'high possibility'. No breakage from those patches yet :). Thanks, Steve.
On 12 October 2013 14:19, Stephen Kelly <steveire@gmail.com> wrote:
On 10/11/2013 11:49 PM, Rene Rivera wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible.
You mean 'high risk', not 'high possibility'. No breakage from those patches yet :).
Sadly, that doesn't mean much. The test results haven't updated since Thursday and a lot of libraries aren't checked regularly. For one example, iostreams is mostly unmaintained, although I occasionally review patches. I had a quick look at the changes, and noticed this in 'boost/iostreams/chain.hpp': -#if !BOOST_WORKAROUND(BOOST_MSVC, < 1310) +#if !BOOST_WORKAROUND(BOOST_MSVC, == 1310) Which looks wrong to me. That was on the second screen of the changes, and there are a lot more screens after that. The rest of it might be fine, but it's unlikely that they'll get checked soon. Also, I asked you not to make these changes until after the release was made here: http://lists.boost.org/Archives/boost/2013/09/206537.php Which you seemed to agree to. We should wait for a little while after the release to give people a chance to respond to the release notes. You also should notify library maintainers before making non-trivial changes to their libraries.
On 10/12/2013 05:11 PM, Daniel James wrote:
On 12 October 2013 14:19, Stephen Kelly <steveire@gmail.com> wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible. You mean 'high risk', not 'high possibility'. No breakage from those
On 10/11/2013 11:49 PM, Rene Rivera wrote: patches yet :). Sadly, that doesn't mean much. The test results haven't updated since Thursday and a lot of libraries aren't checked regularly. For one example, iostreams is mostly unmaintained, although I occasionally review patches. I had a quick look at the changes, and noticed this in 'boost/iostreams/chain.hpp':
-#if !BOOST_WORKAROUND(BOOST_MSVC, < 1310) +#if !BOOST_WORKAROUND(BOOST_MSVC, == 1310)
That's part of a private/template friend workaround. Elsewhere in boost that workaround is applied for MSVC 7.1, so I concluded the < 1310 was a mistake, and it should have been a <= 1310 before. That's unrelated to the new patches though. That patch is from September.
Which looks wrong to me. That was on the second screen of the changes, and there are a lot more screens after that. The rest of it might be fine, but it's unlikely that they'll get checked soon.
Also, I asked you not to make these changes until after the release was made here:
http://lists.boost.org/Archives/boost/2013/09/206537.php
Which you seemed to agree to.
Sorry. I didn't see any connection between the release (on the release branch), and trunk. I asked about that, but didn't get useful information back, so I asked again for permission to proceed. I'll stop committing until a few days after the final release.
We should wait for a little while after the release to give people a chance to respond to the release notes.
You also should notify library maintainers before making non-trivial changes to their libraries.
I'm doing that by writing to this list, right? Thanks, Steve.
Le 13/10/13 10:28, Stephen Kelly a écrit :
On 12 October 2013 14:19, Stephen Kelly <steveire@gmail.com> wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible. You mean 'high risk', not 'high possibility'. No breakage from those
On 10/11/2013 11:49 PM, Rene Rivera wrote: patches yet :). Sadly, that doesn't mean much. The test results haven't updated since Thursday and a lot of libraries aren't checked regularly. For one example, iostreams is mostly unmaintained, although I occasionally review patches. I had a quick look at the changes, and noticed this in 'boost/iostreams/chain.hpp':
-#if !BOOST_WORKAROUND(BOOST_MSVC, < 1310) +#if !BOOST_WORKAROUND(BOOST_MSVC, == 1310) That's part of a private/template friend workaround. Elsewhere in boost
On 10/12/2013 05:11 PM, Daniel James wrote: that workaround is applied for MSVC 7.1, so I concluded the < 1310 was a mistake, and it should have been a <= 1310 before.
That's unrelated to the new patches though. That patch is from September. This is the kind of changes that you need to confirm with the maintainer.
Which looks wrong to me. That was on the second screen of the changes, and there are a lot more screens after that. The rest of it might be fine, but it's unlikely that they'll get checked soon.
Also, I asked you not to make these changes until after the release was made here:
http://lists.boost.org/Archives/boost/2013/09/206537.php
Which you seemed to agree to. Sorry. I didn't see any connection between the release (on the release branch), and trunk. I asked about that, but didn't get useful information back, so I asked again for permission to proceed. Daniel is right. During the release period, it is better to have an stable trunk.
I'll stop committing until a few days after the final release.
We should wait for a little while after the release to give people a chance to respond to the release notes. You also should notify library maintainers before making non-trivial changes to their libraries. I'm doing that by writing to this list, right?
If you don't get the permission from the authors/maintainers or review managers explicitly you shouldn't commit. If them don't replay, contact them personally. Best, Vicente
On 13 October 2013 12:51, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 13/10/13 10:28, Stephen Kelly a écrit :
I'm doing that by writing to this list, right?
If you don't get the permission from the authors/maintainers or review managers explicitly you shouldn't commit. If them don't replay, contact them personally.
Well, sometimes a library's maintainer is no longer concerned with it. In which case we normally just muddle through. But the main point is that notifications should be sent with the name of the libraries affected, since a lot of people don't read threads that don't concern them. Incidentally, this should be easier to mange with git as we'll be able to use pull requests.
On 10/13/2013 02:12 PM, Daniel James wrote:
But the main point is that notifications should be sent with the name of the libraries affected,
If I'm changing 20 libraries, that's not practical.
since a lot of people don't read threads that don't concern them. Incidentally, this should be easier to mange with git as we'll be able to use pull requests.
I don't see what git has to do with it. The modularization I'm trying to do is much much easier now, before migration to mulitple modularized git repos. I have a git-svn checkout. That means I can use git grep. When using modularized git repos I have to write a much more awkward git submodule foreach with a || true at the end. Thanks, Steve.
On 13 October 2013 19:55, Stephen Kelly <steveire@gmail.com> wrote:
On 10/13/2013 02:12 PM, Daniel James wrote:
But the main point is that notifications should be sent with the name of the libraries affected,
If I'm changing 20 libraries, that's not practical.
That's going to be a problem no matter which route you take.
since a lot of people don't read threads that don't concern them. Incidentally, this should be easier to mange with git as we'll be able to use pull requests.
I don't see what git has to do with it. The modularization I'm trying to do is much much easier now, before migration to mulitple modularized git repos. I have a git-svn checkout. That means I can use git grep. When using modularized git repos I have to write a much more awkward git submodule foreach with a || true at the end.
Because each pull request can be tracked in github, which will reduce the administrative burden. It'll also be easier to make the changes on a branch so that you don't disrupt other people's work. And of course merging should be better. When I said it would be easier to manage, I wasn't talking about the initial changes.
On 12/10/2013 10:19 a.m., Stephen Kelly wrote:
On 10/11/2013 11:49 PM, Rene Rivera wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible.
You mean 'high risk', not 'high possibility'. No breakage from those patches yet :).
Thanks,
Boost trunk build is once again broken. This time, an extra parenthesis at boost/function_types/detail/cv_traits.hpp:25 May I ask you to try and build/test Boost before pushing your changes in the future? That doesn't guarantee it will build everywhere, but at least it will let you catch this kind of simple errors. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 10/13/2013 02:38 AM, Agustín K-ballo Bergé wrote:
On 12/10/2013 10:19 a.m., Stephen Kelly wrote:
On 10/11/2013 11:49 PM, Rene Rivera wrote:
In this case we wanted to hold off on trunk commits that had a high probability of breaking many things while we worked on the beta. As people needed to get test cycled as quickly as possible.
You mean 'high risk', not 'high possibility'. No breakage from those patches yet :).
Thanks,
Boost trunk build is once again broken. This time, an extra parenthesis at boost/function_types/detail/cv_traits.hpp:25
Fixed now, thanks.
May I ask you to try and build/test Boost before pushing your changes in the future? That doesn't guarantee it will build everywhere, but at least it will let you catch this kind of simple errors.
I did run most of the tests, but I must have missed function_types somehow... Even with function_types/detail/cv_traits.hpp fixed, I'm still getting errors stephen@hal:~/dev/src/boost-trunk/libs/function_types/test{master}$ ../../../b2 ...patience... ...found 1531 targets... ...updating 8 targets... gcc.compile.c++ ../../../bin.v2/libs/function_types/test/nonmember_ccs.test/gcc-4.8/debug/nonmember_ccs.o custom_ccs/nonmember_ccs.cpp:19:5: error: #error "test not supported with this compiler/platform" # error "test not supported with this compiler/platform" ^ I don't see how that test could *not* fail for me, and I don't see anything in the Jamfile to restrict that test to certain platforms. Any idea what's going on? Thanks, Steve.
On 13/10/2013 05:20 a.m., Stephen Kelly wrote:
On 10/13/2013 02:38 AM, Agustín K-ballo Bergé wrote:
May I ask you to try and build/test Boost before pushing your changes in the future? That doesn't guarantee it will build everywhere, but at least it will let you catch this kind of simple errors.
I did run most of the tests, but I must have missed function_types somehow...
Even with function_types/detail/cv_traits.hpp fixed, I'm still getting errors stephen@hal:~/dev/src/boost-trunk/libs/function_types/test{master}$ ../../../b2 ...patience... ...found 1531 targets... ...updating 8 targets... gcc.compile.c++ ../../../bin.v2/libs/function_types/test/nonmember_ccs.test/gcc-4.8/debug/nonmember_ccs.o custom_ccs/nonmember_ccs.cpp:19:5: error: #error "test not supported with this compiler/platform" # error "test not supported with this compiler/platform" ^
I don't see how that test could *not* fail for me, and I don't see anything in the Jamfile to restrict that test to certain platforms.
It seems the test checks for compiler specific functionality, and chose a weird way of acting on compilers that do not have said functionality. I would have just made the entire test a no-op on those compilers. You may want to create a ticket for this, so the author checks it. In any case, running the tests before and after your changes and then diffing them should be enough to spot those trivial syntax errors. You certainly don't need to fix test that were already failing. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
participants (6)
-
Agustín K-ballo Bergé -
Daniel James -
Rene Rivera -
Stephen Kelly -
Steven Watanabe -
Vicente J. Botet Escriba