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> 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] > *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/89e14bfd/attachment.html>
