In general, that's not a common practice with bug trackers.  Some of the
reasons include:

 * There are often multiple release branches -- do you close it when it
hits the first branch, or close it when it hits all possible branches?
 * It makes it much harder to close bugs because it creates a huge lag
between when someone works on a bug and when they have to go back, find the
bug, and mark it closed.
 * The person working on the bug and the person creating a release may be
different people.

Changelists for releases are the best place for this sort of information.
 Also, including the version number at the time of the fix (or intended
version number the fix should appear in) can help mitigate the search issue.

 - Ken



On Tue, Mar 5, 2013 at 1:33 PM, Piyush <piyushk@gmail.com> wrote:

> Hey folks,
>
> It seems like issues on the ros repository on github are closed as
> soon as a fix is pushed to source, but have not made it to the release
> repository. Would it make more sense to tag them as fixed but close
> the issue only once they've made it to release? It seems to be taking
> me a long time to trace out whether an updated version of a package
> (for instance catkin) has been released with a fix since the bug was
> reported.
>
> Thoughts?
>
> Thanks,
> Piyush
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>