[Range] Proposal: a sub-maintainer of Boost.Range
Dear Neil, Dear Nate, First I'd like to say thank you for your library, Neil. It is a very useful library and it's great fun to writing codes with range adaptors. Boost.Range is one of the most important Boost libraries that are not yet added to the Standard. I know that Neil has made an effort to make time for developing the library, but recently making time for development seems difficult. And there are several open tickets of trivial bugs (e.g. #5603, #6110). Considering this situation, I'd like to make a proposal about Boost.Range: ** Adding a sub-maintainer to Boost.Range ** This reduces author's maintenance burden and also helps more stable development of the library. I recommend Nathan Ridge as a sub-maintainer of Boost.Range. His knowledge, experiences and contribution to Boost are great. If both of Neil and Nate accept the proposal, and if Nate needs some support for the start-up, I'll try my best to support him. I also believe that Jeff will also support him ;) Neil, what do you think about this proposal? I would appreciate and respect any of your reply. Yours sincerely, Michel
On 27-11-2012 12:04, Michel Morin wrote:
Considering this situation, I'd like to make a proposal about Boost.Range:
** Adding a sub-maintainer to Boost.Range **
This reduces author's maintenance burden and also helps more stable development of the library.
I would like to see a more liberal policy towards maintenance. For example, there are many people that are knowledgable and responciple, and which can easily apply patches that have been agreed on. Therefore I see a "sub-maintainer" role as too narrow; why should he not be able to patch a different library as long as the ticket has been discussed and the solution approved by the official maintainers? -Thorsten
Thorsten Ottosen wrote:
On 27-11-2012 12:04, Michel Morin wrote:
Considering this situation, I'd like to make a proposal about Boost.Range:
** Adding a sub-maintainer to Boost.Range **
This reduces author's maintenance burden and also helps more stable development of the library.
I would like to see a more liberal policy towards maintenance. For example, there are many people that are knowledgable and responciple, and which can easily apply patches that have been agreed on. Therefore I see a "sub-maintainer" role as too narrow; why should he not be able to patch a different library as long as the ticket has been discussed and the solution approved by the official maintainers?
How is this any different than the current policy? The "official maintainer" can grant permission to anyone else to he want's to to load patches or whatever. I have done this from time to time with good results. But more frequently I find that those who submit suggestions/bugs /enhancements aren't willing to run the test suite on their own computer much less take ownership for issues that result. A typical example someone adds serialization for some component like boost::variant. This works fine on a couple of compilers. Then it the test fails on some less used compiler - then what? Who deals with this? People making these "small" submissions generally fail to appreciate what it takes to keep a library maintained. I'm not really blaming them it's just that the idea that "a little extra help" is going to help a little over-optimistic in my opinion. Robert Ramey
-Thorsten
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thorsten Ottosen wrote:
On 27-11-2012 12:04, Michel Morin wrote:
Considering this situation, I'd like to make a proposal about Boost.Range:
** Adding a sub-maintainer to Boost.Range **
This reduces author's maintenance burden and also helps more stable development of the library.
I would like to see a more liberal policy towards maintenance. For example, there are many people that are knowledgable and responciple, and which can easily apply patches that have been agreed on.
Even with that policy model (i.e. Boost committers and a Boost.Range sub-maintainer can apply patches), I think that having a knowledgable sub-maintainer is good for the library. Regards, Michel
On Wed, Nov 28, 2012 at 7:44 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
On 27-11-2012 23:27, Michel Morin wrote:
Even with that policy model (i.e. Boost committers and
a Boost.Range sub-maintainer can apply patches), I think that having a knowledgable sub-maintainer is good for the library.
No argument there.
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy. I think Thorsten raises a good point about a general process change to promote fast application of non-contentious patches. I think these are what, quite understandably, frustrate our user base the most when we can't get these applied due to illness or other circumstance. While I have been slow with Boost.Range I think there are examples of slow patches to much more significant issues elsewhere in the Boost libraries. I feel that during periods with more free time I should probably have looked to help mend these libraries too. Perhaps we should simply have an idiom of asking for help more readily when we are busy. The existing Boost maintainers are very decent folk and would have helped me if I had been sensible enough to ask for assistance earlier. I have a lot of respect for Robert's concern that one would have degradation to libraries by allowing excessive openness. I think having a high barrier to entry to become a maintainer should remain. As maintainers perhaps we should all look at more active open tickets than our own and try and chip in on other areas where we feel we can help. I intend doing this during the 2014 after my work schedule abates and my health returns. In summary, I think the processes are good. I've simply not applied my usual work practices to Boost, asking for help occasionally should certainly be acceptable and perhaps even become the norm during periods of high activity / low development resource availability. -Thorsten
Neil Groves
Neil, Neil Groves wrote:
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy. [...]
Thank you for your considered reply, I appreciate it. I'll ask Nate to be a sub-maintainer of Boost.Range.
Neil Groves
I hope your health is good and your work is going well. We're all looking forward to developing Boost with you! Yours sincerely, Michel
Nate, Neil Groves wrote:
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy.
Is it OK for you to be a sub-maintainer of Boost.Range? I think becoming a Boost developer is an exciting experience, isn't it? If it's OK, then let's ask John for subversion account invitation. Regards, Michel
Nate,
Neil Groves wrote:
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy.
Is it OK for you to be a sub-maintainer of Boost.Range? I think becoming a Boost developer is an exciting experience, isn't it?
I am honoured that the Boost[.Range] community deems me fit for this responsibility. First let me echo Michel in thanking Neil for such an awesome library! It speaks to the usefulness and importance of this library and its underlying concepts that ranges are being considered for inclusion in the next C++ standard, with Boost.Range being a (perhaps the primary?) candidate for a reference implementation. I am thus eager to contribute to its development and maintenance. I confess, while I am a heavy user of Boost.Range, I have not spent much time looking at its implementation yet. (I have been meaning to, though, and this role would provide me with an excellent opportunity to do so.) I'm also new to much of the Boost development infrastructure, such as testing, documentation, and version control. I am happy to spend some time learning about these things to become an effective sub-maintainer. Things may be a bit slow-going at first, and I will definitely need some help and guidance in this role. (Thank you, Michel, for offering me help in an earlier mail - I will gladly take you, and anyone else willing to help, up on it). So, assuming a bit of a slow start given the above is acceptable to the community, I am happy to become a sub-maintainer of Boost.Range, and I look forward to working together with you (all) in this role! Regards, Nate
Nathan Ridge wrote:
Neil Groves wrote:
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy.
Is it OK for you to be a sub-maintainer of Boost.Range? I think becoming a Boost developer is an exciting experience, isn't it?
I am honoured that the Boost[.Range] community deems me fit for this responsibility. [...] So, assuming a bit of a slow start given the above is acceptable to the community, I am happy to become a sub-maintainer of Boost.Range, and I look forward to working together with you (all) in this role!
Thanks for your positive reply, Nate. This is indeed good news for the Boost community. Start-up period is definitely not a problem, let's proceed step by step :) Regards, Michel
John, I proposed Nathan Ridge for a sub-maintainer of Boost.Range. As can be seen from the following post, we have positive replies both from the Boost.Range author, Neil Groves, and from Nathan Ridge. May I request you to give svn write access to Nate? His e-mail address is `zeratul976 AT hotmail.com`. Nathan Ridge wrote:
Neil Groves wrote:
I'm very happy for Nate to apply patches. I have seen enough of Nate's good work to know that he would add significant value. I am very keen for this to happen as it will be good for the user-base generally. I think we can just do this without a change to policy. [...] So, assuming a bit of a slow start given the above is acceptable to the community, I am happy to become a sub-maintainer of Boost.Range, and I look forward to working together with you (all) in this role!
Regards, Michel
Nathan Ridge wrote:
I am happy to spend some time learning about these things to become an effective sub-maintainer. Things may be a bit slow-going at first, and I will definitely need some help and guidance in this role. (Thank you, Michel, for offering me help in an earlier mail - I will gladly take you, and anyone else willing to help, up on it).
I'll post several messages which I hope to help you. (I don't intend to make you hurry; I just want to write them down before I forget them :) Regards, Michel
Below is a description of SVN configuration, commit and merge. A good exercise for committing and merging would be: * adding yourself to libs/maintainers.txt (after Neil Groves) [SVN configuration] Here is how I set up my system for write access to the Boost subversion repository. 1. Modify the subversion configuration (~/.subversion/config) for mime-type and eol-style, according to the following link https://svn.boost.org/trac/boost/wiki/BoostSubversion#MIMETypesandEnd-Of-Lin... 2. Creating a working copy with authentication svn co https://svn.boost.org/svn/boost/trunk boost-trunk --username MY_USERNAME [Commit] When I commit, I do the following command svn commit --username MY_USERNAME -m 'COMMIT_LOG' If the commit log contains fix #XXXX (or fixes #XXXX, fixed #XXXX) then the trac ticket #XXXX is automatically closed by the post-commit hook. The commit log is also automatically added to the trac ticket as a comment. Some libraries close trac tickets when the fix is committed to trunk, but other libraries do not close trac tickets until the fix is merged to release. For such libraries, refs #XXXX can be used to automatically add the commit log to the trac ticket as a comment (without closing the ticket). [Merge] I've never done a merge, so I cannot say about it... Boost wiki has some information on merging: https://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromd... Regards, Michel
Below is a description of the Boost documentation. I attached a patch for typos in Boost.Range documentation. Fixing these typos and rebuild docs might be a good start-up. [Documentation] Some library distributes both QuickBook docs (in libs/XXXX/doc) and HTML docs (in libs/XXXX/doc/html), and other library only distributes QuickBook docs. Here is how to update docs and commit them for the libraries with both qbk and html docs. 1. Update quickbook docs. 2. Regenerate HTML docs. 3. Commit them. [Build QuickBook docs] Building QuickBook docs is done by running b2 (bjam) at libs/XXXX/doc directory. cd PATH_TO_BOOST_ROOT_DIR/libs/XXXX/doc PATH_TO_BOOST_ROOT_DIR/b2 (or just b2 if the path is accessible) So, first, one needs to build b2 (bjam) binary by running bootstrap script at the boost root directory. cd PATH_TO_BOOST_ROOT_DIR ./bootstrap.sh (or ./bootstrap.bat on Windows) Then, one needs to add documentation tools: xsltproc, docbook-xsl and docbook-xml-4.2. Here is a how-to for this step. 1. Install xsltproc and add the following to user-config.jam: using xsltproc : PATH_TO_XSLTPROC ; 2. Download Docbook XSL ( http://sourceforge.net/projects/docbook/files/docbook-xsl/ ) The latest version seems work fine. If you'd be more conservative, then use the same version as your target library. For example, Boost.Range uses V1.75.2. 3. Download Docbook XML 4.2 ( http://www.docbook.org/xml/4.2/docbook-xml-4.2.zip ) 4. Add the following to user-config.jam: using boostbook : PATH_TO_DOCBOOK_XSL_DIR : PATH_TO_DOCBOOK_XML_DIR ; A few libraries needs Doxygen to build qbk docs. For those libraries, one needs to install Doxygen and add `using doxygen : PATH_TO_DOXYGEN ;` to user-config.jam. For more information, please consult the installation guide in QuickBook documentation: http://www.boost.org/doc/html/quickbook/install.html Regards, Michel
On 12/2/2012 8:20 AM, Michel Morin wrote:
Here is how to update docs and commit them for the libraries with both qbk and html docs. 1. Update quickbook docs. 2. Regenerate HTML docs. 3. Commit them.
Actually, it's generally discouraged to check in generated files. This goes for html that's generated from quickbook. The preferred thing for docs is to integrate your library's doc build with the overall boost doc build by editing $BOOST/doc/Jamfile.v2. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 2 December 2012 16:36, Eric Niebler <eric@boostpro.com> wrote:
On 12/2/2012 8:20 AM, Michel Morin wrote:
Here is how to update docs and commit them for the libraries with both qbk and html docs. 1. Update quickbook docs. 2. Regenerate HTML docs. 3. Commit them.
Actually, it's generally discouraged to check in generated files. This goes for html that's generated from quickbook. The preferred thing for docs is to integrate your library's doc build with the overall boost doc build by editing $BOOST/doc/Jamfile.v2.
Or if you want to keep the documentation standalone, I can add it to my build script. But if you must check in the generated documentation, delete the generated html files before rebuilding (so that old pages don't hang around) and make sure you add any new pages.
On 12/2/2012 8:54 AM, Daniel James wrote:
On 2 December 2012 16:36, Eric Niebler <eric@boostpro.com> wrote:
The preferred thing for docs is to integrate your library's doc build with the overall boost doc build by editing $BOOST/doc/Jamfile.v2.
Or if you want to keep the documentation standalone, I can add it to my build script.
I hope your build script is checked in somewhere. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 2 December 2012 17:18, Eric Niebler <eric@boostpro.com> wrote:
I hope your build script is checked in somewhere.
It was in a private repo, because it contained hard-coded passwords, but I've been working on getting it safe to make public. I've checked a fresh repo here: https://github.com/danieljames/boost-build-docs It might not work at the moment.
But if you must check in the generated documentation, delete the generated html files before rebuilding (so that old pages don't hang around) and make sure you add any new pages.
How do you do that with Subversion? If I delete the "html" folder and then regenerate it, it shows up with a "~" status ("versioned item obstructed by some item of a different kind"). How do you recover from that? Thanks, Nate
On 12/12/2012 10:23 PM, Nathan Ridge wrote:
But if you must check in the generated documentation, delete the generated html files before rebuilding (so that old pages don't hang around) and make sure you add any new pages.
How do you do that with Subversion?
If I delete the "html" folder and then regenerate it, it shows up with a "~" status ("versioned item obstructed by some item of a different kind"). How do you recover from that?
I think the best thing to do is to delete the "html" folder in the repository on the server, then do an SVN update to wipe out the local "html" folder. Once you are finished with the documentation, regenerate the docs in the local "html" add back thay "html" folder locally to SVN and your commit should add it back on the server.
But if you must check in the generated documentation, delete the generated html files before rebuilding (so that old pages don't hang around) and make sure you add any new pages.
How do you do that with Subversion?
If I delete the "html" folder and then regenerate it, it shows up with a "~" status ("versioned item obstructed by some item of a different kind"). How do you recover from that?
I think the best thing to do is to delete the "html" folder in the repository on the server, then do an SVN update to wipe out the local "html" folder. Once you are finished with the documentation, regenerate the docs in the local "html" add back thay "html" folder locally to SVN and your commit should add it back on the server.
Doesn't that make the history huge, because the entire html files will appear in the diff twice, rather than just the actual changes? Also, doesn't it require two commits (though I guess that's not a big problem)? Regards, Nate
On 12/2/2012 8:20 AM, Michel Morin wrote:
Here is how to update docs and commit them for the libraries with both qbk and html docs. 1. Update quickbook docs. 2. Regenerate HTML docs. 3. Commit them.
Actually, it's generally discouraged to check in generated files. This goes for html that's generated from quickbook. The preferred thing for docs is to integrate your library's doc build with the overall boost doc build by editing $BOOST/doc/Jamfile.v2.
I filed a bug [1] for integrating Bost.Range's doc build into the overall boost doc build. Until that is done, I will check in generated docs along with quickbook docs when I make doc updates. Regards, Nate [1] https://svn.boost.org/trac/boost/ticket/7789
Below is a description of Trac. Fixing #5603, #6110 would be a good start-up: https://svn.boost.org/trac/boost/ticket/5603 https://svn.boost.org/trac/boost/ticket/6110 [Trac] Active tickets of Boost.Range can be displayed via "Custom Query": https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&component=range&col=id&col=summary&col=status&col=owner&col=type&order=priority To receive notification of updates in the Boost.Range tickets, do the following: 1. Subscribe Boost-bugs list: http://lists.boost.org/mailman/listinfo.cgi/boost-bugs 2. On your email client, filter out mails from Boost-bugs that do not have "Component: range" Regards, Michel
Fixing #5603, #6110 would be a good start-up: https://svn.boost.org/trac/boost/ticket/5603 https://svn.boost.org/trac/boost/ticket/6110
Fixed in trunk (r81890 and r82071, respectively). Given that these fixes were trivial, is it appropriate to put them into the 1.53 release? Thanks, Nate
On Dec 18, 2012, at 1:32 AM, Nathan Ridge <zeratul976@hotmail.com> wrote:
Fixing #5603, #6110 would be a good start-up: https://svn.boost.org/trac/boost/ticket/5603 https://svn.boost.org/trac/boost/ticket/6110
Fixed in trunk (r81890 and r82071, respectively).
Given that these fixes were trivial, is it appropriate to put them into the 1.53 release?
The current status of the release branch is "1.53.0 Closed, except for bug fixes and doc changes". <http://www.boost.org/development/index.html> This will be the case until 12/31. So, merging bug fixes to the release branch is not only allowed, but encouraged. However, if I were you, I would wait until some of the test bots cycled, to make sure that nothing is broken - then merge to release. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
However, if I were you, I would wait until some of the test bots cycled, to make sure that nothing is broken - then merge to release.
I assume I'm supposed to be looking here [1] and here [2]. I have a few questions about what I'm seeing: 1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these? 2. At [2], I see that Boost.Range has "issues": the 'type_erased' test is failing (in yellow colour) on a number of testers. Looking back at [1], I see those yellow boxes under 'type_erased' and the corresponding testers, but I also see yellow boxes under other tests, which do not show up as issues in [2]. What makes 'type_erased' special that its failure causes an "issue", but not the failure of other tests? 3. Is there a way to look at older test results, so that I can compare test results from before my commit to test results from after my commit, so that I can see whether my commit specifically broke anything? Thanks! Nate [1] http://www.boost.org/development/tests/trunk/developer/range.html [2] http://www.boost.org/development/tests/trunk/developer/issues.html
However, if I were you, I would wait until some of the test bots cycled, to make sure that nothing is broken - then merge to release. I assume I'm supposed to be looking here [1] and here [2]. I have a few questions about what I'm seeing:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these? Yes. It is up to the maintainer to update the status/expected_results.xml file to indicate that this is a test running correctly, so that a regression is seen red instead of yellow. Unfortunately I don't think a lot of maintainers know that an even those
Le 19/12/12 10:17, Nathan Ridge a écrit : that know (as me) don't maintain this file.
2. At [2], I see that Boost.Range has "issues": the 'type_erased' test is failing (in yellow colour) on a number of testers. Looking back at [1], I see those yellow boxes under 'type_erased' and the corresponding testers, but I also see yellow boxes under other tests, which do not show up as issues in [2]. What makes 'type_erased' special that its failure causes an "issue", but not the failure of other tests?
I think this is a summary for some compilers, but I don't know which ones and why not all the testers are considered.
3. Is there a way to look at older test results, so that I can compare test results from before my commit to test results from after my commit, so that I can see whether my commit specifically broke anything? No that I know. You can try to see if testers that did a run before your commit are working or not.
HTH, Vicente
Le 19/12/12 11:38, Vicente J. Botet Escriba a écrit :
However, if I were you, I would wait until some of the test bots cycled, to make sure that nothing is broken - then merge to release. I assume I'm supposed to be looking here [1] and here [2]. I have a few questions about what I'm seeing:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these? Yes. It is up to the maintainer to update the status/expected_results.xml file to indicate that this is a test running correctly, so that a regression is seen red instead of yellow. Unfortunately I don't think a lot of maintainers know that an even
Le 19/12/12 10:17, Nathan Ridge a écrit : those that know (as me) don't maintain this file.
2. At [2], I see that Boost.Range has "issues": the 'type_erased' test is failing (in yellow colour) on a number of testers. Looking back at [1], I see those yellow boxes under 'type_erased' and the corresponding testers, but I also see yellow boxes under other tests, which do not show up as issues in [2]. What makes 'type_erased' special that its failure causes an "issue", but not the failure of other tests?
I think this is a summary for some compilers, but I don't know which ones and why not all the testers are considered.
3. Is there a way to look at older test results, so that I can compare test results from before my commit to test results from after my commit, so that I can see whether my commit specifically broke anything? No that I know. You can try to see if testers that did a run before your commit are working or not.
BTW, note that there are some testers that are reporting errors for warnings and that some testers as BP x86_64 C++11 <http://www.boost.org/development/tests/trunk/BP%20x86_64%20C++11.html> for clang- linux- 3.2_c++11_libc++ are not working at all. Vicente
Hi Nate, Thanks for committing the fixes! Nathan Ridge wrote:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these?
At least, `type_erased` and `strided` have been failing for some time. IIRC, `strided` still has a bug, which can be found at http://thread.gmane.org/gmane.comp.lib.boost.devel/211955/focus=212004 This bug might be the origin of the `strided` test failure.
2. [...]
3. Is there a way to look at older test results, so that I can compare test results from before my commit to test results from after my commit, so that I can see whether my commit specifically broke anything?
I think it's not possible and it's a drawback of the Boost's testing infrastructure. I guess that one of the reasons (for not storing older test results) is that the test logs are very large. Regards, Michel
Nathan Ridge wrote:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these?
At least, `type_erased` and `strided` have been failing for some time. IIRC, `strided` still has a bug, which can be found at http://thread.gmane.org/gmane.comp.lib.boost.devel/211955/focus=212004 This bug might be the origin of the `strided` test failure.
OK, thanks for letting me know. Since they have been failing for some time, the failures are very likely unrelated to my bug fixes, so I will go ahead and merge those. I will then look at these failing tests when I get a chance. Regards, Nate
Nathan Ridge wrote:
Nathan Ridge wrote:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these?
At least, `type_erased` and `strided` have been failing for some time. IIRC, `strided` still has a bug, which can be found at http://thread.gmane.org/gmane.comp.lib.boost.devel/211955/focus=212004 This bug might be the origin of the `strided` test failure.
OK, thanks for letting me know. Since they have been failing for some time, the failures are very likely unrelated to my bug fixes, so I will go ahead and merge those.
Yes, please :) After the merge, don't forget to add "fixes #5603 and #6110" to Boost 1.53 release notes! You can directly update (via subversion) website/public_html/live/feed/history/boost_1_53_0.qbk or you can post the release notes to "[1.53.0] Release Notes" thread. If you need an example of the release notes, please see https://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost_... And here is the release schedule for Boost 1.53. ( http://www.boost.org/community/ ) - 1.53.0 Closed, except by permission (Monday, December 31) - 1.53.0 Begin beta RC build (Thursday, January 3, 2013) - 1.53.0 Beta release (Monday, January 7, 2013) - 1.53.0 Closed, except by permission (Monday, January 28, 2013) - 1.53.0 Begin RC build (Thursday, January 31, 2013) You can find general information of the release schedule at: https://svn.boost.org/trac/boost/wiki/ReleaseSchedule Regards, Michel
Nathan Ridge wrote:
Nathan Ridge wrote:
1. At [1], I see a number of yellow "fail" boxes. The legend describes this as "failure on a newly added test/compiler". Should I be worried about these?
At least, `type_erased` and `strided` have been failing for some time. IIRC, `strided` still has a bug, which can be found at http://thread.gmane.org/gmane.comp.lib.boost.devel/211955/focus=212004 This bug might be the origin of the `strided` test failure.
OK, thanks for letting me know. Since they have been failing for some time, the failures are very likely unrelated to my bug fixes, so I will go ahead and merge those.
Yes, please :)
After the merge, don't forget to add "fixes #5603 and #6110" to Boost 1.53 release notes! You can directly update (via subversion) website/public_html/live/feed/history/boost_1_53_0.qbk or you can post the release notes to "[1.53.0] Release Notes" thread. If you need an example of the release notes, please see https://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost_...
Done - thanks! Regards, Nate
Neil, The following documentation bugs currently have the status "assigned": https://svn.boost.org/trac/boost/ticket/5160 https://svn.boost.org/trac/boost/ticket/5314 https://svn.boost.org/trac/boost/ticket/5440 Does this mean you have started working on them? If not, can I go ahead and fix them? They seem like trivial fixes to me. Happy New Year! Regards, Nate
What is the purpose of having each of the following: 1. The code snippet containing an example of using the 'adjacent_filtered' range adaptor in libs/range/doc/reference/adaptors/adjacent_filtered.qbk 2. libs/range/doc/reference/adaptors/examples/adjacent_filtered.cpp (seems to be the exact same as the code snippet). 3. libs/range/test/adaptor_test/adjacent_filtered_example.cpp (seems to be the exact same plus some Boost.Test stuff) To modify the example, is it necessary to manually make the same change to all three files, or is there some build process that auto-generates from one of them the two others? Thanks, Nate
Nathan Ridge wrote:
What is the purpose of having each of the following:
1. The code snippet containing an example of using the 'adjacent_filtered' range adaptor in libs/range/doc/reference/adaptors/adjacent_filtered.qbk
This code snippet should be replaced by the example file of 2. This can be done using "import" directive: http://boost-sandbox.sourceforge.net/doc/html/quickbook/syntax/block.html#qu... Its qbk file (tools/quickbook/doc/block.qbk) and the imported cpp file (stub.cpp) are an good example of how to use "import" directive.
2. libs/range/doc/reference/adaptors/examples/adjacent_filtered.cpp (seems to be the exact same as the code snippet).
3. libs/range/test/adaptor_test/adjacent_filtered_example.cpp (seems to be the exact same plus some Boost.Test stuff)
Hmm..., to remove this redundancy, I think we need to add "code snippet markup" to the test file and import it into qbk doc (and delete the example file): http://boost-sandbox.sourceforge.net/doc/html/quickbook/syntax/block.html#qu... Attached a sample of a marked-up cpp file. The code snippet can be imported into adjacent_filtered.qbk by replacing `` ... `` with [import ../../../test/adaptor_test/adjacent_filtered_example.cpp] [foo] You might want to ask what the best markup for this purpose is at Boost.Documentation mailing list. Regards, Michel
On Thu, Jan 3, 2013 at 7:34 AM, Michel Morin <mimomorin@gmail.com> wrote:
What is the purpose of having each of the following:
1. The code snippet containing an example of using the 'adjacent_filtered' range adaptor in
Nathan Ridge wrote: libs/range/doc/reference/adaptors/adjacent_filtered.qbk
This code snippet should be replaced by the example file of 2. This can be done using "import" directive:
http://boost-sandbox.sourceforge.net/doc/html/quickbook/syntax/block.html#qu... Its qbk file (tools/quickbook/doc/block.qbk) and the imported cpp file (stub.cpp) are an good example of how to use "import" directive.
This is a good suggestion. I didn't realise this was possible. This is the only reason for the redundancy.
2. libs/range/doc/reference/adaptors/examples/adjacent_filtered.cpp (seems to be the exact same as the code snippet).
It is the same. I have been aware that of the redundancy, but at the time failed to find a solution that was practical within my release time frame. I added tests for all examples so this redundancy is entirely my fault. I didn't realise there was a better way. Hence if you see something better please feel free to abandon my suboptimal practices. Feel empowered to do whatever makes sense. Your recent work has more than earned this freedom.
3. libs/range/test/adaptor_test/adjacent_filtered_example.cpp (seems to be the exact same plus some Boost.Test stuff)
Hmm..., to remove this redundancy, I think we need to add "code snippet markup" to the test file and import it into qbk doc (and delete the example file):
http://boost-sandbox.sourceforge.net/doc/html/quickbook/syntax/block.html#qu...
Attached a sample of a marked-up cpp file. The code snippet can be imported into adjacent_filtered.qbk by replacing `` ... `` with [import ../../../test/adaptor_test/adjacent_filtered_example.cpp] [foo]
You might want to ask what the best markup for this purpose is at Boost.Documentation mailing list.
This is fantastic! I did not realise this was possible. I hoped and I looked but I failed to find this feature. Clearly, on reflection, I should have asked the list.
Regards, Michel
Thank you Michel and Nathan for your excellent help with Boost.Range. Regards, Neil Groves
Neil Groves wrote: [...]
Thank you Michel and Nathan for your excellent help with Boost.Range.
Thank you for your kind reply, Neil! BTW, Mailing list of ISO C++ Study Group for Ranges (SG9) has been opened by Marshall Clow (and Keld Simonsen): http://www.open-std.org/mailman/listinfo/ranges Shouldn't we subscribe it? :) Regards, Michel
On Jan 4, 2013, at 9:54 PM, Michel Morin <mimomorin@gmail.com> wrote:
Neil Groves wrote: [...]
Thank you Michel and Nathan for your excellent help with Boost.Range.
Thank you for your kind reply, Neil!
BTW, Mailing list of ISO C++ Study Group for Ranges (SG9) has been opened by Marshall Clow (and Keld Simonsen):
http://www.open-std.org/mailman/listinfo/ranges
Shouldn't we subscribe it? :)
Absolutely! BTW, here are the references that I pointed people at in the initial message to the ML: * Boost.Range <http://www.boost.org/doc/libs/1_52_0/libs/range/doc/html/index.html> * Andrei Alexendrescu: "Iterators Must Go!" Boostcon Keynote 2009 <http://blip.tv/boostcon/boostcon-2009-keynote-2452140> * The D programming language standard library <http://dlang.org/phobos/std_range.html> * Range arguments for container constructors and methods <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3456.html> -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Michel Morin wrote:
IIRC, `strided` still has a bug, which can be found at http://thread.gmane.org/gmane.comp.lib.boost.devel/211955/focus=212004 This bug might be the origin of the `strided` test failure.
Filed a ticket for `strided.cpp` test failure. #7824 "++--rng.end() == rng.end()" can fail for strided ranges ( https://svn.boost.org/trac/boost/ticket/7824 ) The testcase in the above mentioned thread is incorrect, so I updated it and attached to the ticket. Regards, Michel
I'll post several messages which I hope to help you. (I don't intend to make you hurry; I just want to write them down before I forget them :)
Thanks, Michel, this information is very helpful! I have a couple of questions:
.. Creating a working copy with authentication svn co https://svn.boost.org/svn/boost/trunk boost-trunk --username MY_USERNAME
What is my username?
Some libraries close trac tickets when the fix is committed to trunk, but other libraries do not close trac tickets until the fix is merged to release.
Which does Boost.Range do? Regards, Nate
Hi Nate, You can request one using the instructions at: https://svn.boost.org/trac/boost/wiki/BoostSubversion#DeveloperAccesstoSubve... Cheers, Glen On Mon, Dec 3, 2012 at 2:41 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
I'll post several messages which I hope to help you. (I don't intend to make you hurry; I just want to write them down before I forget them :)
Thanks, Michel, this information is very helpful!
I have a couple of questions:
.. Creating a working copy with authentication svn co https://svn.boost.org/svn/boost/trunk boost-trunk --username MY_USERNAME
What is my username?
Some libraries close trac tickets when the fix is committed to trunk, but other libraries do not close trac tickets until the fix is merged to release.
Which does Boost.Range do?
Regards, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Nathan Ridge wrote:
.. Creating a working copy with authentication svn co https://svn.boost.org/svn/boost/trunk boost-trunk --username MY_USERNAME
What is my username?
The subversion account request (done in this thread) seems to have failed to catch moderators' eyes. So, let's follow the official procedure for the svn write access request, as Glen suggested: https://svn.boost.org/trac/boost/wiki/BoostSubversion#DeveloperAccesstoSubve...
Some libraries close trac tickets when the fix is committed to trunk, but other libraries do not close trac tickets until the fix is merged to release.
Which does Boost.Range do?
Boost.Range uses "closing at commit time" (though I prefer "closing at merge time" since it is sometimes useful to prevent forgetting to merge). Regards, Michel
participants (11)
-
Daniel James -
Edward Diener -
Eric Niebler -
Glen Fernandes -
Marshall Clow -
Michel Morin -
Nathan Ridge -
Neil Groves -
Robert Ramey -
Thorsten Ottosen -
Vicente J. Botet Escriba