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