[ros-users] Unsubscribe

[Alex Regueiro]

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