Re: [boost] General advice needed for new maintainers.

Subject: Re: [boost] General advice needed for new maintainers.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-02-13 15:49:57

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.
>

You just need to be logged in.

> 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.
>

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.
>

libs/maintainers.txt
https://svn.boost.org/trac/boost/report/15

> 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.
>

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