On Mar 24, 2017 11:32 AM, "Nash, George" <george.nash at intel.com> wrote:
I am not sure I like the practice of closing a bug just because it is old or has not been worked on. I think it is very good to review the old tickets to check it they are still valid. (I don?t think a single open ticket below the 100 in the list was worth keeping open.) Currently Jira is used for a few things that I can see bugs, tasks, and feature requests. - As long as a bug is valid it should probably be left open. There are many examples of bugs being resolved years after they have been reported. - If the bug is no longer valid it should be closed. These are found by regular review of tickets as we are doing now. - Tasks these are the requests to improve some aspect of the code, documentation, sdk, etc. Typically its clear if these will be worked on or not. Still many people can agree that a task is a good idea while not having time to work on it for a long time. - Feature requests are good indication what users want to do with the code that they are not able to do. Sometimes they affect the specification. Some can be implemented without changing the specification. Some are closed because they just don?t fit with the projects goals. My point is age is a bad way to decide if a bug should be closed. Only reason I can see using age to close a bug is if there is an old bug that does not have enough information to properly fix the ticket. Age is also useful for tasks and features since the older they become, does indicate that they hold less importance for the project well and diplomatically put. ;) +1000 George *From:* Christian Gran [mailto:gran at lynxtechnology.com] *Sent:* Friday, March 24, 2017 2:01 AM *To:* Dave Thaler <dthaler at microsoft.com>; Nash, George < george.nash at intel.com>; iotivity-dev at lists.iotivity.org; Philippe Coval < philippe.coval at osg.samsung.com> *Subject:* Re: Jira cleanup Hi, thanks Dave and George, this is very good input. In my oinion the minimal thing we should do with tickets we want to keep is: 1) agree on someone who owns the ticket (assign) 2) check in 3 month if the ticket has been worked on (may be split into other tickets, resolved as outdated, ?) For a ticket where we are unable to find someone who can own it I would suggest to close it - it does not make sense to use Jira as a white board to collect tickets that no one can work on. How does this sound? thanks Christian On 24 Mar 2017, at 01:23, Dave Thaler <dthaler at microsoft.com> wrote: *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: iotivity-dev-bounces at lists.iotivity.org <iotivity-dev-bounces at lists.iotivity.org>] *On Behalf Of *Nash, George *Sent:* Thursday, March 23, 2017 1:41 PM *To:* Christian Gran <gran at lynxtechnology.com>; iot ivity-dev at lists.iotivity.org *Subject:* Re: [dev] Jira cleanup Christian, I took the time to work through all of the tickets that were in the filter. I was able to close a few of the issues as fixed, will not fix, or cannot reproduce. Great, thanks George! If the 119 issues that still show up in the filter I saw 19 that maybe should be looked at again. There were a lot of tickets I simply don?t have the expertise to judge if they should be closed or open. Even some of the list ones I am not really sure. Quite a few of the tickets are analysis of the state of the code as a whole with some suggestions for improving. Because of the analysis it?s hard to recommend closing them. Many of the listed tickets are not defined in a way that they are easy to close and should probably be reworked to set a clear objective. https://jira.iotivity.org/browse/IOT-841 memory catastrophe in IoTivity A very complete analysis of IoTivity memory management. Places we need to improve to make IoTivity more reliable for running long periods of time https://jira.iotivity.org/browse/IOT-723 Remove all use of snprintf and sscan from the embeddable parts of the stack The primary justification for this change is for embedded stacks. Since iotitivity constrained is intended for embedded stacks this bug may not be as important as it was when it was introduced. I am not sure if the recommendation to remove all use is justified but in a lot of the code the suggestion could be used. As platform support maintainer, I agree with closing it. https://jira.iotivity.org/browse/IOT-708 Subscribing to Presence is ill defined to the point of not working Bug points out places where subscribing to presence presence does not work. I am unsure if recent updates have addressed the issues. https://jira.iotivity.org/browse/IOT-653 Multi Hop using Routing Manager This is more a feature request. With a link to wiki page describing the feature. With a really long well written analysis in the comments of the ticket. https://jira.iotivity.org/browse/IOT-645 [Limits Build Server] SCons is generating output from dependencies in the 'extlibs' directory in the wrong directory; should be in the 'out' directory, but it generates them inside their respective library's home dir. This basically address the problem that building the extlibs causes problems with build process when building under different build options. The suggestion it to build extlibs in the out folder. This also has the benefit of isolating build output to one location instead of spread throughout the project. https://jira.iotivity.org/browse/IOT-619 RA xmpp scons need to execute the build directly with SConscript It is unclear if this is fixed or not (https://gerrit.iotivity.org/ gerrit/#/c/1639 ) If this is not fixed this could cause intermittent build failures that are hard to track down. https://jira.iotivity.org/browse/IOT-601 C and C++ SDKs need to compile with GCC options {{-fvisibility=hidden -fvisibility-inlines-hidden}} Try a prevent polluting the global symbol space for the linker. Phil, as Ubuntu sub-maintainer, do you have a recommendation on the disposition of IOT-601? https://jira.iotivity.org/browse/IOT-582 Iotivity's Android build process does not follow proper Gradle implementation standards. We have seen issues that the *.aar files may have missing libraries till a second build is completed it may be related to this issue. This also has a proposed solution and a commit that will need to be updated. I think this should be revisited. Rick Bell (as Android sub-maintainer) should probably make the call here. https://jira.iotivity.org/browse/IOT-540 Subsystem for Legacy ZigBee Devices Feature request to expose ZigBee devices as IoTivity resources. This may no longer be needed or needs to be reworked for bridging. https://wiki.iotivity.org/legacy_zigbee_device_support https://jira.iotivity.org/browse/IOT-519 Refactor #ifdef's as feature-based, not OS based No discussion in the comments. In general I think the suggestion is a good idea question remains if it is something that should be done in IoTivity Yes, the https://wiki.iotivity.org/platform_support page already states this guidance. I?ll take the bug for now, but since this is lower-priority cleanup, if someone else wants it feel free. https://jira.iotivity.org/browse/IOT-513 Fully implement 32-bit build processes in 64-bit SCons environment on Ubuntu. There was not justification for the ticket but often the only way for most developers to test and verify code for 32-bit is to build on their 64-bit system. This has a changeset that was done but abandoned. Relates to IOT-511. Phil, as Ubuntu sub-maintainer, do you have a recommendation on the disposition of IOT-513? https://jira.iotivity.org/browse/IOT-497 Proposal for reduced file descriptor consumption https://jira.iotivity.org/browse/IOT-496 Change network interface monitoring Change how network interfaces are managed to reduce idle load and reduce code complexity. https://jira.iotivity.org/browse/IOT-494 Opportunities for simplifying CSDK Pointes out several problem areas that code complexity could be improved. (i.e. layers of calls, duplication of function, proliferation of structures, excess marshaling, misleading and confusing nomenclature, excessive use of threads). I think this is an important bug but it?s so big it should probably be broken up in to smaller tasks that can each be tracked instead of this monster list of problems. (this was also pointed out as an important ticket by Thiago Moura in a recent email regarding Arduino) I agree 494 should be replaced by more granular bugs. We shouldn?t have ?laundry list? bugs that include multiple unrelated items. https://jira.iotivity.org/browse/IOT-441 Make IoTivity restart system calls interrupted by Unix signals Make IoTivity handle EINTR system call properly. Looks like a lot of work was done on this issue. It?s unclear if more work needs to be done. Phil, any preference? https://jira.iotivity.org/browse/IOT-440 Make IoTivity CLOEXEC-safe Make IoTivity thread-safely when using open, dup, dup2, pipe, socket, and accept. Another one that looks like it was partially completed. It looks like it should have been handed off to another team. Unsure it this needs to be looked into deeper. https://jira.iotivity.org/browse/IOT-415 Cannot handle fast notification in ClientSever Mode Based on the comments on this ticket it is unclear if this is an invalid bug or if it should be looked into deeper. No really clear close case for this issue that I can see. https://jira.iotivity.org/browse/IOT-347 Building documentation not documented Is the wiki documentation enough to satisfy this ticket? If so it can be closed https://wiki.iotivity.org/generate_api_doc if not it still needs improvement. https://jira.iotivity.org/browse/IOT-122 Avoid using reinterpret_cast >From the the comments it looks like this one may be able to be closed. I looked at some of the uses of the reinterpret_cast and it really does feel like it?s being used to force the code to be used in an unusual way. *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: iotivity-dev-bounces at lists.iotivity.org <iotivity-dev-bounces at lists.iotivity.org>] *On Behalf Of *Christian Gran *Sent:* Monday, March 20, 2017 2:32 AM *To:* iotivity-dev at lists.iotivity.org *Subject:* Re: [dev] Jira cleanup Hi, just a reminder that we want to close outdated tickets by end of March. We are now down to 124 tickets that will be closed at that time. thanks Christian On 10 Mar 2017, at 09:59, Christian Gran <gran at lynxtechnology.com> wrote: Hi, there are currently 141 issues in Jira, that are in open state and have not been updated for more then 6 month now. The plan is to clean up Jira and close outdated tickets by end of March. If you see a ticket, that you still want to keep - please just add a comment to it. This will update the ?updated date? field and it will no longer be part of the filtered tickets. For the list of tickets, please use this Jira filter: status in (Open, "In Progress", Reopened, Assigned, "To Do", "In Review") AND updated <= -180d or just this link https://jira.iotivity.org/issues/?jql=status%20in%20( Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Assigned% 2C%20%22To%20Do%22%2C%20%22In%20Review%22)%20AND%20updated%20%3C%3D%20-180d <https://jira.iotivity.org/issues/?jql=status%20in%20(Open,%20%22In%20Progress%22,%20Reopened,%20Assigned,%20%22To%20Do%22,%20%22In%20Review%22)%20AND%20updated%20%3C=%20-180d> Please feel free to comment, or if you have some more input how we can make sure that we only keep issues in Jira we are actually working on?. thanks Christian _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170324/217b3ab8/attachment.html>
