Re: [boost] [1.55.0] Release candidate 2 available
On 11/5/2013 1:46 AM, LeMay.Steve wrote:
VS2013 needs archive's transform_width.hpp to #include <algorithm> so that std::min will be properly defined.
Looks like it. Can you file the bug please? -- Eric Niebler Boost.org http://www.boost.org
On Tue, Nov 05, 2013 at 11:46:46AM +0100, Eric Niebler wrote:
On 11/5/2013 1:46 AM, LeMay.Steve wrote:
VS2013 needs archive's transform_width.hpp to #include <algorithm> so that std::min will be properly defined.
Looks like it. Can you file the bug please?
This has been filed since the first of July. https://svn.boost.org/trac/boost/ticket/8757 I believe this is stuck in Ramey's territory as he has in another thread mentioned something about "bundling all pending patches together and some unrelated one broke". So... S11n is completely screwed and I'm truly happy I've migrated away from it already. -- Lars Viklund | zao@acc.umu.se
On 11/5/2013 6:41 AM, Lars Viklund wrote:
On Tue, Nov 05, 2013 at 11:46:46AM +0100, Eric Niebler wrote:
On 11/5/2013 1:46 AM, LeMay.Steve wrote:
VS2013 needs archive's transform_width.hpp to #include <algorithm> so that std::min will be properly defined.
Looks like it. Can you file the bug please?
This has been filed since the first of July. https://svn.boost.org/trac/boost/ticket/8757
I believe this is stuck in Ramey's territory as he has in another thread mentioned something about "bundling all pending patches together and some unrelated one broke".
So... S11n is completely screwed and I'm truly happy I've migrated away from it already.
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Edward Diener wrote:
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Am I the only one who finds this a bit odd? It's a trivial one-line fix, adding a missing #include. Someone should just go ahead and merge it.
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Am I the only one who finds this a bit odd? It's a trivial one-line fix, adding a missing #include. Someone should just go ahead and merge it.
+1, adding a missing std lib #include (which should always have been there, it just wasn't exposed before) is a no-brainer. Just my 2c worth, John.
On 06.11.2013 13:09, John Maddock wrote:
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Am I the only one who finds this a bit odd? It's a trivial one-line fix, adding a missing #include. Someone should just go ahead and merge it.
+1, adding a missing std lib #include (which should always have been there, it just wasn't exposed before) is a no-brainer.
Other projects have the 'obvious' rule, where fixes like this may be committed by anybody with commit access, no approvals, just CC to mailing list required. Shall we officially have such rule? - Volodya
On Wed, Nov 6, 2013 at 1:19 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 06.11.2013 13:09, John Maddock wrote:
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Am I the only one who finds this a bit odd? It's a trivial one-line fix, adding a missing #include. Someone should just go ahead and merge it.
+1, adding a missing std lib #include (which should always have been there, it just wasn't exposed before) is a no-brainer.
Other projects have the 'obvious' rule, where fixes like this may be committed by anybody with commit access, no approvals, just CC to mailing list required.
Shall we officially have such rule?
For one, I'm very much in favor of such rule, although I don't see how it will work with git.
On Wed, Nov 6, 2013 at 10:23 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
For one, I'm very much in favor of such rule, although I don't see how it will work with git.
Aren't there boost members/maintainers that will have access to all official git repositories? Authors should be easily able to pull and merge these changes in their work repos afterward, if it's a different one.
On Wed, Nov 6, 2013 at 1:28 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
On Wed, Nov 6, 2013 at 10:23 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
For one, I'm very much in favor of such rule, although I don't see how it will work with git.
Aren't there boost members/maintainers that will have access to all official git repositories? Authors should be easily able to pull and merge these changes in their work repos afterward, if it's a different one.
I can create a pull request, true. But until someone accepts it, the build is still broken. And if the library maintainer is unresponsive, this may lead to situations like the one we're discussing. If there are "supervisors" who have access to all repositories, this helps but not much. The supervisors may miss the pull request or be busy with other things.
On Wed, Nov 6, 2013 at 10:35 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
If there are "supervisors" who have access to all repositories, this helps but not much. The supervisors may miss the pull request or be busy with other things.
So there would be a need for some kind of "moderator"-like role where most library maintainers volunteer to maintain sometime others libraries too?
On 06.11.2013 13:35, Andrey Semashev wrote:
Aren't there boost members/maintainers that will have access to all official git repositories? Authors should be easily able to pull and merge these changes in their work repos afterward, if it's a different one. I can create a pull request, true. But until someone accepts it, the build is still broken. And if the library maintainer is unresponsive, this may lead to situations like the one we're discussing. Git is a _distributed_ version control system. Different people should probably have write access to different repositories. The release manager should probably have his own set of library repositories and process pull requests for these repositories. Individual library developers should have their own repositories. They should create pull requests if they want to include their changes into the next boost release.
If the library is broken and the library developer is unresponsive, anybody can clone the repository, fix the bug and create the pull request to the release manager. The library developer can merge this changeset to his repository later. Currently, this newsgroup is used for pull requests: - The release branch is now closed. - I would like to merge 84402 to release. - This looks ok to me. Please go ahead. - Thanks. Committed as revision 86519. - I would like to merge if possible this fix https://svn.boost.org/trac/boost/changeset/86547 for this bug https://svn.boost.org/trac/boost/ticket/9337 . - In my opinion, it's too late for 1.55. We've already rolled RC2, and the release has already been delayed. -- Sergey Cheban
Vladimir Prus wrote:
Other projects have the 'obvious' rule, where fixes like this may be committed by anybody with commit access, no approvals, just CC to mailing list required.
Shall we officially have such rule?
In this specific case this rule would have no effect. We're talking about merging the fix from trunk to release, at a time such merging requires permission from the release managers.
On 5 November 2013 21:55, Peter Dimov <lists@pdimov.com> wrote:
Edward Diener wrote:
I noticed the 'trunk' version of transform_width.hpp does have the fix, so there is some reason Mr. Ramey has not updated 'release' with it.
Am I the only one who finds this a bit odd? It's a trivial one-line fix, adding a missing #include. Someone should just go ahead and merge it.
There are a lot of things that someone should be doing, and they don't seem to get done. I think it might be for the best to stop relying on someone.
Daniel James wrote:
There are a lot of things that someone should be doing, and they don't seem to get done. I think it might be for the best to stop relying on someone.
Good general advice, but inapplicable here. Only the release managers have the authority to go forward with this.
On 6 November 2013 12:39, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
There are a lot of things that someone should be doing, and they don't seem to get done. I think it might be for the best to stop relying on someone.
Good general advice, but inapplicable here. Only the release managers have the authority to go forward with this.
It's too late. There were reports of this after the first release candidate (and earlier), and no one did anything. Regardless, Visual C++ 12 isn't even listed as a test compiler and there are numerous problems with it, it's not worth delaying the release further.
On 06.11.2013 16:56, Daniel James wrote:
It's too late. There were reports of this after the first release candidate (and earlier), and no one did anything. There were only 4 days between RC1 and RC2.
Regardless, Visual C++ 12 isn't even listed as a test compiler and there are numerous problems with it, it's not worth delaying the release further. I don't know why VC12 isn't listed as a test compiler. We have the regression test results for it:
http://www.boost.org/development/tests/release/teeks99-10-win2008-64on64.htm... http://www.boost.org/development/tests/trunk/teeks99-10-win2008-64on64.html -- Sergey Cheban
On 6 November 2013 14:34, Sergey Cheban <s.cheban@drweb.com> wrote:
On 06.11.2013 16:56, Daniel James wrote:
It's too late. There were reports of this after the first release candidate (and earlier), and no one did anything.
There were only 4 days between RC1 and RC2.
I managed to get a change in during that period, as did others. The problem was present in the beta release, which was about a month ago, so there was time to deal with it.
Regardless, Visual C++ 12 isn't even listed as a test compiler and there are numerous problems with it, it's not worth delaying the release further.
btw. that's my opinion, not an official "release manager" statement. Just in case that wasn't clear.
I don't know why VC12 isn't listed as a test compiler. We have the regression test results for it:
The list only includes testers that were available at the time of the beta release. Visual C++ 12 was added quite late in the release cycle, and initial test runs were not very regular.
On 11/5/2013 5:46 AM, Eric Niebler wrote:
On 11/5/2013 1:46 AM, LeMay.Steve wrote:
VS2013 needs archive's transform_width.hpp to #include <algorithm> so that std::min will be properly defined.
Looks like it. Can you file the bug please?
As I said in an earlier email the fix is in trunk but not merged to release - related to tickets: #9279/#8750 Evidently this single simple fix is held up by other (non)related issues involving TYPE_TRAIT deprecation of which I'm not familiar. Jeff
participants (11)
-
Andrey Semashev -
Daniel James -
Edward Diener -
Eric Niebler -
Jeff Flinn -
John Maddock -
Klaim - Joël Lamotte -
Lars Viklund -
Peter Dimov -
Sergey Cheban -
Vladimir Prus