On 05.03.2013 14:13, Piyush wrote: > Yeah, I agree that the change lists are not updated for every fix and > I can understand why. The REP change you've recommended should improve > the situation considerably. > > I also second Ken's point about mentioning the intended version number > for the fix while closing the bug report. This should make the issue > thread self contained, and makes it easy enough for the commiter to > do. I have found this extremely useful in the past. That sounds like a good recommendation for maintainers. Can you add that to the bugtracking paragraph at http://www.ros.org/wiki/DevelopersGuide ? Thanks, - Dirk > On Tue, Mar 5, 2013 at 3:58 PM, Dirk Thomas wrote: >> The visibility of which fixes have made it into a release of a package is >> provided with the change log of a package. >> Recently those information are not maintained very well in Wiki pages as >> they require quite some effort to maintain. >> >> The new REP specifying in-source change log files will hopefully improve >> that situation significantly. >> Furthermore these information would then also be available in the Debian >> package as well as in the Wiki. >> >> - Dirk >> >> >> >> On 05.03.2013 13:50, Austin Hendrix wrote: >>> >>> I've occasionally had this problem as well. >>> >>> I'm not sure github supports this, but on other ticketing systems, you can >>> move a bug to a "release pending" state once the change has been tested and >>> merged into the main repository. >>> >>> On github, I would probably do this by opening a meta-issue for each >>> release, and then all fixes that go into that release can reference it. That >>> way we can close individual issues once they're >>> committed, and then close the meta-issue when the release happens. >>> >>> Thoughts? >>> -Austin >>> >>> On 03/05/2013 01:47 PM, Ken Conley wrote: >>>> >>>> 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 >>> > 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 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >