Subject: [boost] General advice needed for new maintainers.
From: Fletcher, John P (j.p.fletcher_at_[hidden])
Date: 2014-02-13 15:05:37
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.
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 past fixes to find out what has gone on. Someone suggested searching but I cannot search until I know what is there.
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 pages myself to check them when I am making changes, which may be substantial.
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.
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.
There is quite a lot here, but it has been building up for some time as I find I need more information to work effectively.
John Fletcher
P.S. Thanks to all those who have helped me get this far.