Hi, we are talking here about two different things - that somehow got mixed up:
1) get a clean state: Looking at Jira today twe have more than 100 tickets that have not been looked at for more then 6 month. We need to do something about this. My proposal to the group was - that everyone has a look at these tickets and updates the ones that are important. The ones no one is interested in should be handled as well - in my opinion closed - as no miracle happens here. If someone wants to step forward - and it sounds like we have candidates here - to look at all of these and own these - I?m totally ok with that as well. Just do something to help to clean these out. 2) define a process moving forward that such a bad state never will be reached again: We need a process to handle tickets that have not been looked at for a while. Using a state called ?stalled? is totally fine. My suggestion was to look at these and increase their priority every 3 month - if - and only if these are valid tickets. Then the high priority tickets need to be worked on first. As this is an open source project we will always get reports with different quality - valid bugs and tickets and not so valid as well. There will be no magic way to handle this - and just ignoring old tickets - what seems to be the current way to handle this, does not work for me neither. I?m quite sure we can agree on this. thanks Christian On 24 Mar 2017, at 23:34, C.J. Collier <cjcollier at linuxfoundation.org<mailto:cjcollier at linuxfoundation.org>> wrote: Indeed. I'm with George on this. We can create a new "stalled" state that we can put aging tickets in to. We could then filter out stalled issues from the default search list or the like. New contributors could then be set to the task of resolving stalled issues when they request a first project. A productive hazing ritual, as it were. Cheers, C.J. Sent from my PDP-11 On Mar 24, 2017 09:32, "Nash, George" <george.nash at intel.com<mailto: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. George From: Christian Gran [mailto:gran at lynxtechnology.com<mailto:[email protected]>] Sent: Friday, March 24, 2017 2:01 AM To: Dave Thaler <dthaler at microsoft.com<mailto:dthaler at microsoft.com>>; Nash, George <george.nash at intel.com<mailto:george.nash at intel.com>>; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; Philippe Coval <philippe.coval at osg.samsung.com<mailto: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<mailto:dthaler at microsoft.com>> wrote: From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Nash, George Sent: Thursday, March 23, 2017 1:41 PM To: Christian Gran <gran at lynxtechnology.com<mailto:gran at lynxtechnology.com>>; iotivity-dev at lists.iotivity.org<mailto:iotivity-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
