Hello, Might the fix for this problem be in there? http://article.gmane.org/gmane.comp.lib.boost.user/27122 Thanks, Jeff
Jeff wrote:
Hello,
Might the fix for this problem be in there? http://article.gmane.org/gmane.comp.lib.boost.user/27122
Thanks, Jeff
Unfortunately not. We are past the point for code changes. Apart from that I would need a patch for RC_1_34_0 Sorry Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Jeff wrote:
Hello,
Might the fix for this problem be in there? http://article.gmane.org/gmane.comp.lib.boost.user/27122
Thanks, Jeff
Unfortunately not. We are past the point for code changes. Apart from that I would need a patch for RC_1_34_0
Maybe, you should file a bug somewhere, so that it's not forgotten for 1.34.1? - Volodya
Vladimir Prus wrote:
Thomas Witt wrote:
Jeff wrote:
Hello,
Might the fix for this problem be in there? http://article.gmane.org/gmane.comp.lib.boost.user/27122
Thanks, Jeff Unfortunately not. We are past the point for code changes. Apart from that I would need a patch for RC_1_34_0
Maybe, you should file a bug somewhere, so that it's not forgotten for 1.34.1?
- Volodya
Just curious: Is there something amiss with the process when a fix that was in the releas for 1_33_1 (from september 2005) doesn't get into 1_34_0? There is another thing I don't quite understand. You are asking that a bug be filed somewhere. However when you look at http://boost.org/more/bugs.htm it recommends reporting it to this list. As far as I can tell this has now been done twice in the last few days in this list. Is there some different procedure of format for reporting bugs that is documented elsewhere?
eg wrote:
Vladimir Prus wrote:
Thomas Witt wrote:
Hello,
Might the fix for this problem be in there? http://article.gmane.org/gmane.comp.lib.boost.user/27122
Thanks, Jeff Unfortunately not. We are past the point for code changes. Apart from
Jeff wrote: that I would need a patch for RC_1_34_0
Maybe, you should file a bug somewhere, so that it's not forgotten for 1.34.1?
- Volodya
Just curious: Is there something amiss with the process when a fix that was in the releas for 1_33_1 (from september 2005) doesn't get into 1_34_0?
The process is to apply fix to HEAD and then merge to branch. I guess just human error was involved -- somebody applied fix to RC_1_33_1 only.
There is another thing I don't quite understand. You are asking that a bug be filed somewhere.
For avoidance of doubt, that question was addressed to Thomas.
However when you look at http://boost.org/more/bugs.htm it recommends reporting it to this list. As far as I can tell this has now been done twice in the last few days in this list.
Which makes it likely that this bug will fall though the cracks again, that's why filing in in a bug tracker is good idea at this point.
Is there some different procedure of format for reporting bugs that is documented elsewhere?
I think bugs.htm may be not telling enough about using tracker, but I don't know who's to change that. - Volodya
Jeff, eg wrote:
Vladimir Prus wrote:
Thomas Witt wrote:
Just curious: Is there something amiss with the process when a fix that was in the releas for 1_33_1 (from september 2005) doesn't get into 1_34_0?
Flat out yes. For starters the iostreams maintainer is MIA.
There is another thing I don't quite understand. You are asking that a bug be filed somewhere. However when you look at http://boost.org/more/bugs.htm it recommends reporting it to this list. As far as I can tell this has now been done twice in the last few days in this list.
The good news is we are trying to improve things. The baf news is everything is in flux. The new bug tracker can be found at http://svn.boost.org I would be thankful if you could log it there.
Is there some different procedure of format for reporting bugs that is documented elsewhere?
AFAICT not yet. As I said things are changing. Thanks Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Is there something amiss with the process when a fix that was in the releas for 1_33_1 (from september 2005) doesn't get into 1_34_0?
Flat out yes. For starters the iostreams maintainer is MIA.
I was wondering about that.
...
The good news is we are trying to improve things. The baf news is everything is in flux.
The new bug tracker can be found at http://svn.boost.org
I would be thankful if you could log it there.
I wasnt the original reporter of this but I have filed this in the tracker: Ticket #953 By the way, did you know that there is no "iostreams" component listed in the tracker at the moment? So I entered it as none. I also may have mislabeled the version and milestone fields... but don't know how to change them. Hope this is helpful.
"eg"
Thomas Witt wrote:
Is there something amiss with the process when a fix that was in the releas for 1_33_1 (from september 2005) doesn't get into 1_34_0?
Flat out yes. For starters the iostreams maintainer is MIA.
[snip]
I wasnt the original reporter of this but I have filed this in the tracker:
Ticket #953
Thomas, I think the issue is much larger than just an outdated zlib.hpp... I just did a simple comparison between the 1.33.1 and 1.34.0 versions of the iostream library source files. (1.33.1 files from a zip when 1.33.1 was first released; 1.34.0 files from zip pulled down this morning.) There are several cases where the files in 1.33.1 are **newer** than the ones in 1.34.0... in many cases by several months: File | 1.33.1 Date | 1.34.0 Date iostreams/checked_operations.hpp | 11/15/2005 | 5/19/2005 iostreams/code_converter.hpp | 11/15/2005 | 6/3/2005 iostreams/compose.hpp | 11/15/2005 | 5/30/2005 iostreams/restrict.hpp | 11/15/2005 | 5/26/2005 iostreams/detail/resolve.hpp | 10/8/2005 | 5/21/2005 iostreams/detail/adapter/concept_adapter.hpp | 11/15/2005 | 5/19/2005 iostreams/detail/adapter/direct_adapter.hpp | 11/15/2005 | 5/19/2005 iostreams/detail/adapter/mode_adapter.hpp | 11/15/2005 | 5/19/2005 iostreams/detail/adapter/non_blocking_adapter.hpp | 11/15/2005 | 5/19/2005 iostreams/detail/adapter/range_adapter.hpp | 11/15/2005 | 5/19/2005 iostreams/detail/streambuf/direct_streambuf.hpp | 11/10/2005 | 7/15/2005 iostreams/device/file.hpp | 11/14/2005 | 8/24/2005 iostreams/device/file_descriptor.hpp | 11/15/2005 | 8/24/2005 iostreams/device/mapped_file.hpp | 11/28/2005 | 5/30/2005 iostreams/device/null.hpp | 11/15/2005 | 5/19/2005 iostreams/filter/aggregate.hpp | 8/29/2005 | 7/15/2005 iostreams/filter/gzip.hpp | 11/14/2005 | 6/8/2005 iostreams/filter/line.hpp | 8/29/2005 | 7/15/2005 iostreams/filter/zlib.hpp | 9/24/2005 | 7/21/2005 I know that you previously stated that the library maintainer was MIA and I don't know when/how the 1.34.0 development started but to an outsider (me) it looks like the iostreams library code was taken from an outdated location - maybe 1.33.0 or maybe before even then... I know that 1.34.0 has "shipped" but given that the entire iostream library looks like it might be based on the wrong version might warrant more immediate action than to wait for 1.34.1... Someone more knowledgable about the library should at least look into the differences in short order and give you an informed opinion as to what's been "lost" so that you can make a decision as to course of action (trigger 1.34.1, 1.34.0 addendum/notice regarding the true state of the library, whatever...). -Chris Woods
[Should this discussion be moved to the developers list?] At 1:07 PM -0400 5/14/07, Christopher Woods wrote:
I think the issue is much larger than just an outdated zlib.hpp... I just did a simple comparison between the 1.33.1 and 1.34.0 versions of the iostream library source files. (1.33.1 files from a zip when 1.33.1 was first released; 1.34.0 files from zip pulled down this morning.) There are several cases where the files in 1.33.1 are **newer** than the ones in 1.34.0... in many cases by several months:
I looked at the list you generated, and then looked at the rest of the iostreams library. It appears that several changes were made on the RC_1_33_0 branch around 20-23 months ago, but that none of those changes was ever made to what was HEAD at the time. As a result, they were not picked up as part of the RC_1_34_0 tag. Without access to the library maintainer (and possibly even then - memories fade), it may be difficult to tell whether this is a case of failure to merge the changes back to HEAD or making the changes on the wrong branch (the RC_1_33_0 branch instead of HEAD). The changes involved were presumably tested as part of testing the 1.33.0 and 1.33.1 releases, so are probably reasonably safe to merge. But certainly not completely safe, since they haven't been tested at all against other changes that are part of 1.34.0. And some spot-checking in other areas of the library found more issues filter/symmetric.hpp positioning.hpp - 1.33.0 changes merged to both trunk and 1.34.0 branch: good chain.hpp - some merging to trunk done, but diffs are large: not sure char_traits.hpp - merge from 1.33.0 to trunk done: good - unmerged change on 1.34.0 branch: bad detail/bool_trait_def.hpp - merged from 1.33.0 to trunk done: good - unmerged change on 1.34.0 branch: bad detail/config/codecvt.hpp - merged from HEAD to 1.34.0 done: good detail/streambuf/indirect_streambuf.hpp - unmerged changes on 1.33.0 branch: bad - unmerged changes on 1.34.0 branch: bad There may well be other problems that I missed.
At 3:34 PM -0400 5/14/07, Kim Barrett wrote:
And some spot-checking in other areas of the library found more issues
[...]
There may well be other problems that I missed.
I'll also volunteer to help clean up this mess. I don't have cvs write access, so will need help from someone who does. I think the first step is to get the current trunk up to date. Then decide what to do about the 1.34.0 branch. If it is decided that changes should be merged to there, I'll help with that too.
Kim Barrett wrote:
[Should this discussion be moved to the developers list?]
I think so (but I'm not the one to do it).
At 1:07 PM -0400 5/14/07, Christopher Woods wrote:
I think the issue is much larger than just an outdated zlib.hpp... I just did a simple comparison between the 1.33.1 and 1.34.0 versions of the iostream library source files. (1.33.1 files from a zip when 1.33.1 was first released; 1.34.0 files from zip pulled down this morning.) There are several cases where the files in 1.33.1 are **newer** than the ones in 1.34.0... in many cases by several months:
I looked at the list you generated, and then looked at the rest of the iostreams library. It appears that several changes were made on the RC_1_33_0 branch around 20-23 months ago, but that none of those changes was ever made to what was HEAD at the time. As a result, they were not picked up as part of the RC_1_34_0 tag.
Without access to the library maintainer ...
I was eager to upgrade to the long awaited 1.34.0, but now I am afraid to do it. We have one use for iostreams, but it's in a major application that cannot afford problems like memory leaks. I am considering lifting the iostreams code from 1.33.1, but the build environment has changed to bjam v2, and I doubt that it would be easy. It seems that the major problem with iostreams is that the developer has disappeared. If that's true, it's not good for Boost's reputation. Perhaps the acceptance of a library into Boost should include a promise to find a successor to maintain the code, if the developer ever needs to move on. Whatever the history, is there a Boost developer that is taking over responsibility for iostreams? I hope that you can find one and that he or she can resolve the problems with the 1.34.0 version. BTW, thanks for finally finishing up the 1.34.0 release. I look forward to 1.34.1 and/or 1.35.0 in the near future. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
participants (7)
-
Christopher Woods -
eg -
Jeff -
Kim Barrett -
Richard Hadsell -
Thomas Witt -
Vladimir Prus