[ros-users] Unsubscribe
Alex Regueiro
alexreg at gmail.com
Tue Mar 5 22:13:53 UTC 2013
On 5 Mar 2013, at 22:13, Piyush <piyushk at gmail.com> 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.
>
> Thanks!
> Piyush
>
> 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
More information about the ros-users
mailing list