Permission to proceed?

older
Re: [boost] Improving Documentation

Stephen Kelly

11 Oct 2013 11 Oct '13

9:33 p.m.

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.

Show replies by date

Steven Watanabe

11 Oct 11 Oct

9:48 p.m.

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

Stephen Kelly

9:46 p.m.

On 10/11/2013 11:48 PM, Steven Watanabe wrote:

...

Commits to the trunk are always okay. Only the release branch gets frozen.

Thanks! I'll push my commits. Steve.

Rene Rivera

9:49 p.m.

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 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

Stephen Kelly

12 Oct 12 Oct

1:19 p.m.

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.

Daniel James

3:11 p.m.

On 12 October 2013 14:19, 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 :).

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.

Stephen Kelly

13 Oct 13 Oct

8:28 a.m.

On 10/12/2013 05:11 PM, Daniel James wrote:

...

On 12 October 2013 14:19, Stephen Kelly 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.

Vicente J. Botet Escriba

11:51 a.m.

Le 13/10/13 10:28, Stephen Kelly a écrit :

...

...
On 12 October 2013 14:19, Stephen Kelly 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

Daniel James

12:12 p.m.

On 13 October 2013 12:51, Vicente J. Botet Escriba 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.

Stephen Kelly

6:55 p.m.

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.

Daniel James

14 Oct 14 Oct

10:31 a.m.

On 13 October 2013 19:55, Stephen Kelly 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.

Agustín K-ballo Bergé

13 Oct 13 Oct

12:38 a.m.

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

Stephen Kelly

8:20 a.m.

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.

Agustín K-ballo Bergé

4:39 p.m.

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

4167

Age (days ago)

4170

Last active (days ago)

List overview

Download

13 comments

6 participants

participants (6)

Agustín K-ballo Bergé
Daniel James
Rene Rivera
Stephen Kelly
Steven Watanabe
Vicente J. Botet Escriba