Re: wrong typedef name in boost::_mfi::[c]mf0

From: david.abrahams_at_[hidden]
Date: 2001-11-22 10:33:30

Aleksey,

Those policies sound exactly right to me. The policy you suggest for 
boost developers is the one that I use myself.

Regards,
Dave

--- In boost_at_y..., Aleksey Gurtovoy <alexy_at_m...> wrote:
> It should be "argument_type" instead of "first_argument_type". 
> 
> I would check in the fix myself ('cause I need it :), but then I 
thought
> that although it's clearly a bug and the fix is trivial, it still 
could be
> considered impolite to make a change in a library code without 
asking the
> author first. So I started with "what should a boost developer 
with CVS
> write access do if she found a trivial bug in other library?", and 
ended up
> with more general "what should one do if she/he found a bug in 
boost
> library?". Apparently, it's not in the FAQ. A proposed answer is 
below:
> 
> 0. Make sure bug isn't already fixed in the latest sources :). The 
most
> recent version of code is available from boost public CVS 
repository.
> 
> 1. If you are a boost user, or a boost developer that doesn't have 
a CVS
> write access:
>     a) submit a bug report to either boost-users list, boost 
mailing list,
> or boost bug tracking facility on SourceForge (BTW, what is the 
preferred
> way?) [Optional: "See bug submitting guidelines for the details 
how to write
> a useful bug report". Optional, because probably we are not yet at 
the stage
> when those are needed.]
>     b) if you have a proposed patch to the code, post it along 
with your bug
> report, preferably in the "context diffs" format (diff -c); if you 
can, send
> a patch relative to the current CVS state.
> 
> 2. If you are a boost developer, and you do have a CVS write 
access:
>     a) if bug is trivial (e.g. misspelled name, missed typename, 
etc.), and
> you are willing to make a fix, go ahead and do it, but post a 
notification
> about your changes to the boost mailing list;
>     b) if bug is not trivial, or/and you don't have time/resources 
to fix
> it, submit a bug report (see p. 1 above).
>     c) otherwise create a temporary branch in CVS, make your 
changes there,
> and ask the library author(s)/maintainer(s) to review them; if 
they are ok
> with the new code, either you or themselves can integrate the 
fixes into the
> main trunk.
> 
> Comments/corrections are welcome :).
> 
> --
> Aleksey