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 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 > 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 >>> 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 >>> >> >> _______________________________________________ >> 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 >