Volunteering to fix inspection issues
I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)? -- Jeremiah Willcock
On Apr 19, 2010, at 8:59 AM, Jeremiah Willcock wrote:
I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)?
I introduced a couple of TABS into boost/array.hpp. Fixed on the trunk (revision 61415) Ok to merge to release? (no other changes) -- Marshall
Hi Boost, I have been working on a serialization solution for a few years. It started out with fundamentally different goals to most other offerings. Most obviously it tackles file and network serialization as one, delivering full network messaging out of the box. It also delivers runtime-selectable encodings. But to get a full picture of what it's about, feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web This library is being used as the basis for further products but there is also the possibility that it might be useful in a standalone way. Technically I would be happy to initiate a Boost review process but realistically I think the library is too big and it overlaps functionally with several existing Boost components including; serialization, asio, MPI, any, uuid, statechart, thread, timer and variant. The underlying concepts for this merging of software technologies comes from two sources; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) Perhaps there is value in the way that the different technologies work together? Or maybe there is value in the approach to serialization that can be added to Boost? Strangely, after mention of lofty topics such as SDL and AO, the only real contender for a Boost submission would appear to be the UTF facillity within the library. So - is there any interest in a Boost UTF component? Cheers, Scott
On 4/19/2010 2:42 PM, Marshall Clow wrote:
On Apr 19, 2010, at 8:59 AM, Jeremiah Willcock wrote:
I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)?
I introduced a couple of TABS into boost/array.hpp. Fixed on the trunk (revision 61415)
Ok to merge to release? (no other changes)
Meta: please don't hijack threads. It makes it harder for Jeremiah to get a response to his post, and makes it impossible for the release managers to spot your request. In the future, start a new thread with an appropriate subject line. To answer your question, I think we're only fixing bugs at this point. The tabs can wait. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 4/19/2010 8:59 AM, Jeremiah Willcock wrote:
I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)?
Jeremiah, Thanks for volunteering! Yes, that sounds like a good procedure. I don't think we need to get every maintainers' permission to fix tabs and newlines in their code. Trunk first, then merge to release. (That could prove tricky if your changes conflict with other unmerged changes. Oh well.) I would avoid making cosmetic changes -- just the inspection stuff. (E.g., don't change formatting at all. Seems innocuous, but it can make diffs difficult.) Again, thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, 20 Apr 2010, Eric Niebler wrote:
On 4/19/2010 8:59 AM, Jeremiah Willcock wrote:
I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)?
Jeremiah,
Thanks for volunteering! Yes, that sounds like a good procedure. I don't think we need to get every maintainers' permission to fix tabs and newlines in their code. Trunk first, then merge to release. (That could prove tricky if your changes conflict with other unmerged changes. Oh well.) I would avoid making cosmetic changes -- just the inspection stuff. (E.g., don't change formatting at all. Seems innocuous, but it can make diffs difficult.)
Yes, I won't change formatting (other than tab expansion). Did you want me to do the trunk only as per your previous email? -- Jeremiah Willcock
On 4/20/2010 9:49 AM, Jeremiah Willcock wrote:
Did you want me to do the trunk only as per your previous email?
Yeah, at this point in the release cycle we'll be taking bug fixes only. Once 1.43 is out, you can merge your fixes to the release branch. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, 20 Apr 2010, Eric Niebler wrote:
On 4/20/2010 9:49 AM, Jeremiah Willcock wrote:
Did you want me to do the trunk only as per your previous email?
Yeah, at this point in the release cycle we'll be taking bug fixes only. Once 1.43 is out, you can merge your fixes to the release branch.
I've done tabs, files not ending in newlines, and the one min/max issue, plus some of the bookmark-related problems. Should I do anything about the Apple macro issue? If the bad names are only used locally to a library's test suite, they should be easy to fix. I'm not so sure about doing ones that are in library source code, since those may be part of the library's interface. -- Jeremiah Willcock
participants (4)
-
Eric Niebler -
Jeremiah Willcock -
Marshall Clow -
Scott Woods