For development of bloom, I create milestones for upcoming releases and target individual issues to one of those versions milestones.<div><br></div><div>This takes some effort on my part, but at least then you can see which version of bloom the issue has been solved for or which one it is planned for, then you can click the milestone and get an idea of the progress towards that release. This is similar to Austin's suggestion of "meta-issues" of which I usually have an issue like "release bloom 0.3.2" as part of the 0.3.2 milestone.<div>
<br></div><div>--<br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 2:18 PM, Dirk Thomas <span dir="ltr"><<a href="mailto:dthomas@willowgarage.com" target="_blank">dthomas@willowgarage.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05.03.2013 14:13, Piyush wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, I agree that the change lists are not updated for every fix and<br>
I can understand why. The REP change you've recommended should improve<br>
the situation considerably.<br>
<br>
I also second Ken's point about mentioning the intended version number<br>
for the fix while closing the bug report. This should make the issue<br>
thread self contained, and makes it easy enough for the commiter to<br>
do. I have found this extremely useful in the past.<br>
</blockquote>
<br></div>
That sounds like a good recommendation for maintainers.<br>
Can you add that to the bugtracking paragraph at <a href="http://www.ros.org/wiki/DevelopersGuide" target="_blank">http://www.ros.org/wiki/<u></u>DevelopersGuide</a> ?<br>
<br>
Thanks,<br>
- Dirk<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Mar 5, 2013 at 3:58 PM, Dirk Thomas <<a href="mailto:dthomas@willowgarage.com" target="_blank">dthomas@willowgarage.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The visibility of which fixes have made it into a release of a package is<br>
provided with the change log of a package.<br>
Recently those information are not maintained very well in Wiki pages as<br>
they require quite some effort to maintain.<br>
<br>
The new REP specifying in-source change log files will hopefully improve<br>
that situation significantly.<br>
Furthermore these information would then also be available in the Debian<br>
package as well as in the Wiki.<br>
<br>
- Dirk<br>
<br>
<br>
<br>
On 05.03.2013 13:50, Austin Hendrix wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've occasionally had this problem as well.<br>
<br>
I'm not sure github supports this, but on other ticketing systems, you can<br>
move a bug to a "release pending" state once the change has been tested and<br>
merged into the main repository.<br>
<br>
On github, I would probably do this by opening a meta-issue for each<br>
release, and then all fixes that go into that release can reference it. That<br>
way we can close individual issues once they're<br>
committed, and then close the meta-issue when the release happens.<br>
<br>
Thoughts?<br>
-Austin<br>
<br>
On 03/05/2013 01:47 PM, Ken Conley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In general, that's not a common practice with bug trackers. Some of the<br>
reasons include:<br>
<br>
* There are often multiple release branches -- do you close it when it<br>
hits the first branch, or close it when it hits all possible branches?<br>
* It makes it much harder to close bugs because it creates a huge lag<br>
between when someone works on a bug and when they have to go back, find the<br>
bug, and mark it closed.<br>
* The person working on the bug and the person creating a release may be<br>
different people.<br>
<br>
Changelists for releases are the best place for this sort of information.<br>
Also, including the version number at the time of the fix (or intended<br>
version number the fix should appear in) can help<br>
mitigate the search issue.<br>
<br>
- Ken<br>
<br>
<br>
<br>
On Tue, Mar 5, 2013 at 1:33 PM, Piyush <<a href="mailto:piyushk@gmail.com" target="_blank">piyushk@gmail.com</a><br>
<mailto:<a href="mailto:piyushk@gmail.com" target="_blank">piyushk@gmail.com</a>>> wrote:<br>
<br>
Hey folks,<br>
<br>
It seems like issues on the ros repository on github are closed as<br>
soon as a fix is pushed to source, but have not made it to the<br>
release<br>
repository. Would it make more sense to tag them as fixed but close<br>
the issue only once they've made it to release? It seems to be taking<br>
me a long time to trace out whether an updated version of a package<br>
(for instance catkin) has been released with a fix since the bug was<br>
reported.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
Piyush<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a> <mailto:<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><u></u>><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</blockquote>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div></div>