AMDG On 02/13/2014 12:05 PM, Fletcher, John P wrote:> I have been maintaining Boost Phoenix for several weeks.
To start with I was mainly attempting to fix as many bugs as possible
and also sorting out things like missing copright and licence. I am now up to the more difficult bugs which take longer to fix.
I also need some more information and some actions which I cannot take
myself. I have asked about a number of these on this list and I am lacking answers to a good many of them, so I am going to summarise them here.
I think it would be a great help to people undertaking maintenance for
the first time, without having first been an originator of a library if some guidelines were in a document.
1. General guidelines on the responsibilities of a maintainer and who
is responsible for the elements outside the developer's control. In particular, what happens when there is a release of boost?
2. General guidelines on the responsibilities for bugs and who to
contact if a bug seems to be due to a different library.
Just reassign the ticket to the correct library.
3. Guidelines on the use of trac and how to get given the ability to record bugs as now fixed.
4. Where is the archive for boost-bugs? It would be useful to look at
You just need to be logged in. past fixes to find out what has gone on. Someone suggested searching but I cannot search until I know what is there.
I don't think there is an archive. You might look at https://svn.boost.org/trac/boost/timeline, though.
5. A list of who is maintaining what.
6. Documentation. I am trying to get to grips with boostbook and quickbook. Some libraries are included in a section with indexed chapters and some are not. Is there a policy about this. When I asked how Phoenix could join the only reply I had was not to bother. Is there a documentation policy? It would be good to be able to generate the web
libs/maintainers.txt https://svn.boost.org/trac/boost/report/15 pages myself to check them when I am making changes, which may be substantial.
The main library index is libs/libraries.htm. The one that you referred to is an artifact of the documentation toolchain. You should be able to generate the documentation for Phoenix by running b2 in libs/phoenix/doc. You'll need to have the docbook dtd and xsl stylesheets. See also: https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted
7. More technical. How are things to be handled in relation to C++11. (a) Things which used to work which now don't with C++11? (b) Things which only work with C++11? (c) and what about C++14? I am fixing things in an adhoc way but it would be good to have a uniform approach.
This is pretty vague. I would generally handle this ad hoc just like you're doing. In general, I would try to make sure that C++03 code was written in a way that still works in the new standard(s) and C++11 only code is protected by #ifdefs using the appropriate Boost.Config macros. If there isn't a macro then ask for one.
8. Boost predef for version numbers. I have introduced this into Phoenix alongside the existing method.
9. Changelog. As a user I have found this useful in libraries I have used elsewhere, so I have put one into Phoenix following the style I found in wave.
It's your choice. I don't see any problem with this. In Christ, Steven Watanabe