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

[Piyush]

I've added some general comments to the wiki page. William's
suggestion is equally effective, and I've included a line about that
as well.

Piyush

On Tue, Mar 5, 2013 at 4:23 PM, William Woodall
<william at osrfoundation.org> wrote:
> For development of bloom, I create milestones for upcoming releases and
> target individual issues to one of those versions milestones.
>
> 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.
>
> --
>
>
> On Tue, Mar 5, 2013 at 2:18 PM, Dirk Thomas <dthomas at willowgarage.com>
> wrote:
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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
>