[ros-users] Closing issues only when fixes reach the release repository

[Dirk Thomas]

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 <dthomas at willowgarage.com> 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 <piyushk at gmail.com
>>>> <mailto:piyushk at 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 at code.ros.org <mailto:ros-users at code.ros.org>
>>>>      https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>