Re: [DISCUSS]Bug Tracking
The problem is not what we choose as bug reporting system but that we all agree on something and we use it Each tool has advantages and disadvantages so JIRA or github should be OK from my side. Alin On Wed, Jan 15, 2020 at 7:59 PM Gregory Nutt wrote: > > > Where does the GitHub Projects reside? What I was pushing for was a > single > > place not per repo. To me the core OS one was the right place, but that > > seems to be off the table, I fail to see how tracking a release including > > the apps (especially if the tickets are open against the apps project) is > > tainting the quality of the OS. > That option is certainly off the table for me. That is the only option > that would force me to vote -1. I will support every other option > suggested. >
Re: [DISCUSS]Bug Tracking
Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. That option is certainly off the table for me. That is the only option that would force me to vote -1. I will support every other option suggested.
RE: [DISCUSS]Bug Tracking
> Where does the GitHub Projects reside? Per repo and per Organization > To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. I think there is a perception that "How good" the OS is should not be judged by "How good" the apps are. So 10 Issues all on Apps and 1 issue against the OS but all logged in the OS repo is what is meeting resistance. Call it "quality inferences" Myself, I do not share that point of view. In my view: an App or OS bug is still a problem if we are using both OS and APPs. I think about where issues belong more as a matter of compartmentalization and not quality inferences: Having apps that has issues focuses the conversation on APPS. Having OS that has issues focuses the conversation on the OS. If a user does not use apps then why tell them of all the issues in the OS repo? If there is linkage use Markup to link them [Effects APP](url) and [Effects OS](url) and that is all that is needed to cross reference them. David -Original Message- From: Brennan Ashton [mailto:bash...@brennanashton.com] Sent: Wednesday, January 15, 2020 10:24 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS]Bug Tracking On Wed, Jan 15, 2020, 10:09 AM David Sidrane wrote: > +1 for Github issues per repo. > > Repos can be cross referenced in markup. > Assignees can be assigned > labels can be assigned. > Projects (roll up across repos) can be assigned. > Milestones can be assigned. > UI is simple and effective Query by any of the above attributes. > The interfaces is present when on Github - there is no need secondary > login/account > The content can be rich. > Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. --Brennan >
Re: [DISCUSS]Bug Tracking
On Wed, Jan 15, 2020, 10:09 AM David Sidrane wrote: > +1 for Github issues per repo. > > Repos can be cross referenced in markup. > Assignees can be assigned > labels can be assigned. > Projects (roll up across repos) can be assigned. > Milestones can be assigned. > UI is simple and effective Query by any of the above attributes. > The interfaces is present when on Github - there is no need secondary > login/account > The content can be rich. > Where does the GitHub Projects reside? What I was pushing for was a single place not per repo. To me the core OS one was the right place, but that seems to be off the table, I fail to see how tracking a release including the apps (especially if the tickets are open against the apps project) is tainting the quality of the OS. --Brennan >
RE: [DISCUSS]Bug Tracking
+1 for Github issues per repo. Repos can be cross referenced in markup. Assignees can be assigned labels can be assigned. Projects (roll up across repos) can be assigned. Milestones can be assigned. UI is simple and effective Query by any of the above attributes. The interfaces is present when on Github - there is no need secondary login/account The content can be rich. We can add issue from email if someone does not have access to github. -1 for any other external issue tracking system. They add no value above what is built into ghithub. They complicate coordination (PR closes issue). In a general sense: The choice if an external system violates 3NF. I do not agree that issues OR Code changes will continue to come in by email. I believe the root cause of that historical dataflow is an artifact bad process and tooling. When the correct process are in place, as is the correct tooling, there can be support for historical manual ways, but it will be less used because it is not as efficient, it is not fool proof or effective. David -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Tuesday, January 14, 2020 5:29 PM To: dev@nuttx.apache.org Subject: Re: [DISCUSS]Bug Tracking I presume that there will be vote coming in the next few days for the Bug Tracking solution. This thread, then, is really the [DISCUSS] thread prior to the vote, right? I have no idea what the voting options will be, but we should probably label this as [DISCUSS] so people will appreciate that it is important for their opinions to be heard.
Re: Bug Tracking
github project boards can span multiple repos https://help.github.com/en/github/managing-your-work-on-github/about-project-boards On Wed, Jan 15, 2020 at 12:09 AM Gregory Nutt wrote: > > > The Mynewt project, for example, has many repositories. I can > > find the page but I recall that it is on the order of a dozen or so > > repositories. ... > > 17 > > See https://gitbox.apache.org/repos/asf > >
Re: Bug Tracking
The Mynewt project, for example, has many repositories. I can find the page but I recall that it is on the order of a dozen or so repositories. ... 17 See https://gitbox.apache.org/repos/asf
Re: Bug Tracking
Part of the issues to consider is that If you use GitHub issues, having multiple repos you may need to enable issues in multiple places. This means more to manage and track. Having all issues for multiple repos on a single github repo also has issues. There would certainly be some scalability issues. The Mynewt project, for example, has many repositories. I can find the page but I recall that it is on the order of a dozen or so repositories. NuttX was, at one point, five repositories. We currently have four (excluding the three or four additional non-Apache support repositories) If the number of repositories becomes large, it is hard to imagine any practical way to manage all of the issues with github issues.
Re: [DISCUSS]Bug Tracking
I presume that there will be vote coming in the next few days for the Bug Tracking solution. This thread, then, is really the [DISCUSS] thread prior to the vote, right? I have no idea what the voting options will be, but we should probably label this as [DISCUSS] so people will appreciate that it is important for their opinions to be heard.
Re: Bug Tracking
My understanding is that most patch will come via the mailing list anyway and it will be mostly up o the PPMX to create and manage the issues for the users. That is true. There was one this morning (my time): "SMTP send mail example build failure"
Re: Bug Tracking
Hi, > Why can't we use both JIRA and Github, since they are linked? The downside would be multiple places to look for issues, They are not closely linked if you raise an issue in GitHub one doesn’t get raised in JIRA. My understanding is that most patch will come via the mailing list anyway and it will be mostly up o the PPMX to create and manage the issues for the users. Thanks, Justin
Re: Bug Tracking
Not apposed to any solution. However, the argument that people not having access to Github is still out there. Why can't we use both JIRA and Github, since they are linked? On Wed, Jan 15, 2020 at 12:50 AM Gregory Nutt wrote: > > > > Speaking about bugzilla. I know JIRA is linked which is what I proposed > > first, but got heavily pushed against. > I didn't perceive things that way. I recall only Alin having a strong > position to use github issues.
Re: Bug Tracking
Speaking about bugzilla. I know JIRA is linked which is what I proposed first, but got heavily pushed against. I didn't perceive things that way. I recall only Alin having a strong position to use github issues.
Re: Bug Tracking
Speaking about bugzilla. I know JIRA is linked which is what I proposed first, but got heavily pushed against. On Tue, Jan 14, 2020, 4:43 PM Justin Mclean wrote: > Hi, > > > I don't believe it has great integration with GitHub (I did not see any > > mention in infra) > > It has some integration e.g. mention a JIRA in a commit message (or PR) > and it automatically get linked up to that JIRA. > > At the ASF Infra manages JIRA so that reduces a little of the load in > regard to this. > > Thanks, > Justin
Re: Bug Tracking
Hi, > I don't believe it has great integration with GitHub (I did not see any > mention in infra) It has some integration e.g. mention a JIRA in a commit message (or PR) and it automatically get linked up to that JIRA. At the ASF Infra manages JIRA so that reduces a little of the load in regard to this. Thanks, Justin
Re: Bug Tracking
I don't believe it has great integration with GitHub (I did not see any mention in infra) and when I used it at RedHat it was really heavy and clunky, and designed to manage all the software under some enterprise organization. The only thing I think it has going for it is that it's opensource unlike JIRA and GitHub and if you manage it, it will work. --brennan On Tue, Jan 14, 2020, 4:25 PM Nathan Hartman wrote: > On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote: > > The implication is the you would be opposed to Bugzilla. Bugzilla is > > more primitive but is has the advantage of being lightweight and fast. > > Most pull-back from Jira would be, I think, because it is a heavyweight > > solution (but also does much more than just track issues). > > I am not opposed but I don't know much about Bugzilla. I've never used > it personally. So I can't argue in favor or against it. If others > support it, then I would be neutral on that. > > Nathan >
Re: Bug Tracking
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote: > Most pull-back from Jira would be, I think, because it is a heavyweight > solution (but also does much more than just track issues). When you say that Jira is a heavyweight solution, do you mean in terms of the infrastructure required to run it, or in terms of how easy/hard it is to use? Nathan
Re: Bug Tracking
On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt wrote: > The implication is the you would be opposed to Bugzilla. Bugzilla is > more primitive but is has the advantage of being lightweight and fast. > Most pull-back from Jira would be, I think, because it is a heavyweight > solution (but also does much more than just track issues). I am not opposed but I don't know much about Bugzilla. I've never used it personally. So I can't argue in favor or against it. If others support it, then I would be neutral on that. Nathan
Re: Bug Tracking
I am fine with either of the following two options (not in any order of preference): (1) GitHub issues with separate issues for each repository, i.e., issues with "apps" are reported against "apps," *not* against NuttX. Pros: Convenience and widespread familiarity across the FOSS world. Cons: Excludes those who can not access GitHub. Does not support an issue that affects both repositories. Not running on ASF infrastructure. (2) Jira, with issues correctly tagged as affecting the OS, or affecting apps, or affecting both. Pros: Running on ASF infrastructure. Inclusiveness for those who cannot use GitHub. Cons: Loss of the conveniences provided by the GitHub option. Of course, I am open to consider other suggestions that might be offered. :-) The implication is the you would be opposed to Bugzilla. Bugzilla is more primitive but is has the advantage of being lightweight and fast. Most pull-back from Jira would be, I think, because it is a heavyweight solution (but also does much more than just track issues).
Re: Bug Tracking
On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean wrote: > Hi, > > Part of the issues to consider is that If you use GitHub issues, having > multiple repos you may need to enable issues in multiple places. This means > more to manage and track. Having all issues for multiple repos on a single > github repo also has issues. > > I don’t think there’s an ideal solution here, I’ve used both JIRA and > GitHub issues in the past and they both have their advantages and > disadvantages. The PPMC needs to come up with a solution that everyone is > willing to work with, even if it is not everyone first choice. It might be > a good idea if each of the 13 PPMC members express their opinion or someone > listed the possible options and people indicated their choice. A valid > opinion would be "I’m fine with any solution”. I am fine with either of the following two options (not in any order of preference): (1) GitHub issues with separate issues for each repository, i.e., issues with "apps" are reported against "apps," *not* against NuttX. Pros: Convenience and widespread familiarity across the FOSS world. Cons: Excludes those who can not access GitHub. Does not support an issue that affects both repositories. Not running on ASF infrastructure. (2) Jira, with issues correctly tagged as affecting the OS, or affecting apps, or affecting both. Pros: Running on ASF infrastructure. Inclusiveness for those who cannot use GitHub. Cons: Loss of the conveniences provided by the GitHub option. Of course, I am open to consider other suggestions that might be offered. :-) Cheers, Nathan
Re: Bug Tracking
Part of the issues to consider is that If you use GitHub issues, having multiple repos you may need to enable issues in multiple places. This means more to manage and track. Having all issues for multiple repos on a single github repo also has issues. I don’t think there’s an ideal solution here, I’ve used both JIRA and GitHub issues in the past and they both have their advantages and disadvantages. The PPMC needs to come up with a solution that everyone is willing to work with, even if it is not everyone first choice. It might be a good idea if each of the 13 PPMC members express their opinion or someone listed the possible options and people indicated their choice. A valid opinion would be "I’m fine with any solution”. Okay... here is my opinion: 1. I don't care if we use Jira, Bugzilla, or Github Issues. You pick. I will support the PPMC's preference with a +1 vote. 2. There is only one option that I want to avoid. If we use Github issues, I would want issues to be enabled in all repositories. The only position I have heard that I am opposed to is enabling issues only on the OS repository then reporting all issues against the OS. I am very STRONGLY opposed to dumping all issues on the OS and that would get a -1 vote from me. The recent discussion about security issues is a case in point. That is, again, a pre-Apache version of a low-effort, application in the apps/ directory... one of those quick, afternoon developments. It would be offensive to report that security issue against the OS which has years of effort is unrelated to the security issue. The OS is not involved and is the wrong place to report that error. It would improperly reflect on the OS. It should be reported against the applications as it was in the Bitbucket apps/ Issues. That is correct. It would be very wrong to report it against the OS. Greg
Re: Bug Tracking
Hi, Part of the issues to consider is that If you use GitHub issues, having multiple repos you may need to enable issues in multiple places. This means more to manage and track. Having all issues for multiple repos on a single github repo also has issues. I don’t think there’s an ideal solution here, I’ve used both JIRA and GitHub issues in the past and they both have their advantages and disadvantages. The PPMC needs to come up with a solution that everyone is willing to work with, even if it is not everyone first choice. It might be a good idea if each of the 13 PPMC members express their opinion or someone listed the possible options and people indicated their choice. A valid opinion would be "I’m fine with any solution”. Thanks, Justin
Bug Tracking
We started a discussion about bug tracking and never really came to a consensus. I notice that the ASF also provides Bugzilla: https://bz.apache.org/bugzilla/ That is an older, simpler tool than Jira but probably also should be considered. I haven't used Bugzilla for years and I can't really remember much about it other than it does track bugs. I don't have any other strong impressions. It is neither slow nor is it complicated. Greg
Re: Bug tracking
Hi, You don’t need an apache account to raise either a GitHub issue or a JIRA issues. > In that reference web page, there is also something called the Contributor's > role that has almost as many privileges as a committer does. I am not > exactly sure what a Contributor role is. I suppose it is a role that we > could assign to any trusted contributor? Correct. Thanks, Justin
Re: Bug tracking
But, I think that the user who hasn't an apache account can't create an issue in JIRA. I don't think that is true, is it? I think it is role-based: https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization It looks like any registered user (even non-committers) can create and link issues, add comments to issues, add attachments to issues. Looks like it would work fine. If Jira is linked to github issues, then users could create issues via github and the PPMC could track everything in Jira. In that reference web page, there is also something called the Contributor's role that has almost as many privileges as a committer does. I am not exactly sure what a Contributor role is. I suppose it is a role that we could assign to any trusted contributor?
Re: Bug tracking
But, I think that the user who hasn't an apache account can't create an issue in JIRA. I don't think that is true, is it? I think it is role-based: https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization It looks like any registered user (even non-committers) can create and link issues, add comments to issues, add attachments to issues. Looks like it would work fine. If Jira is linked to github issues, then users could create issues via github and the PPMC could track everything in Jira.
Re: Bug tracking
But, I think that the user who hasn't an apache account can't create an issue in JIRA. On Sun, Jan 5, 2020 at 10:51 AM Gregory Nutt wrote: > > > >>> Maybe people should not file a bug for hardware-specific issues that > >>> affect only their specific configuration. As you point out, it is > >>> unlikely that anyone else will be able to fix or test such an issue. > >>> So, for those cases, maybe we should encourage people not to file an > >>> issue but rather to fix it right away, and help in any way possible. > >>> > >>> In contrast, for things that affect the RTOS itself, build system, > >>> etc., we would let people file issues. > >> I think that keeping track of issues, prioritized and categorized by > >> sub-system and platform would be of benefit to many users. Attempt to > >> fix every bug on every hardware configuration is not humanly possible. > >> I think fixing bugs would have to be like committers responding to PRs: > >> People will have have "scratch what itches" (or something like that). > >> But just knowing that something has a bug is useful information to users. > > I dont know how github issues work but I know that in Jira, issues can be > > tagged with any number of "tags". Then you can filter by tags and see all > > issues with that tag. > > > > Utilizing this feature, we could have a tag for each supported MCU, and a > > tag for each supported board. > > > > When someone is thinking of using NuttX for their project with a particular > > board, they could look up the known issues and then make an informed > > decision if those issues might affect their project and, if so, if they are > > willing to scratch that itch and fix that issue. > > > > Then obviously what I said before no longer applies and we would encourage > > people to file issues provided they tag them correctly. > > I like that idea of tagging issues. That could prove very useful. > Doesn't github support user-defined tags? I have never used them, but > they seem a little primitive from what I have read. The issues in the > top-level TODO list are not tagged, but grouped by functional areas and > would be unusable if they were not so grouped. A long list of old > ungrouped, untagged github issues would be similarly useless. > > I am not a big fan of selecting a tools then defining your management > processes to match the tool. I prefer to think the other way around. I > spent decades as as system engineer and system architect and I have > top-down thinking in my bones. > > I really don't know anything of significance about Jira so it would be > irresponsible for me to advocate anything either way. Github issues are > great places for discussing current topics. I am more familiar with > Bitbucket issues, and I assume they are similar. My experience is that > if no one takes immediate action on an issue, it lingers, people lose > interest, and the issue fades from group memory. Then years later they > are there in the issue list, out of context, possibly inactionable. > > Issues are good for the immediate reactions to and dialog about an > issue. But that doesn't it really constitutes management of issues. > > At one point Brennan demonstrated that you can link a Jira issue to a > PR. I wonder... can you also link a Jira issue to a github issue. If > so, then why not use both? Users could enter issues into Github, email, > or Jirah. Github issues could support some dialog. Jira might then > provide the missing project management component. > > And what do we do with the old issues still in the Bitbucket Issues? Or > the issues in the TODO list. There are usually issues raised in emails > on daily basis. Most of the time, these are worked out through through > email exchanges, others are not and are just forgotten. > > Greg > >
Re: Bug tracking
Maybe people should not file a bug for hardware-specific issues that affect only their specific configuration. As you point out, it is unlikely that anyone else will be able to fix or test such an issue. So, for those cases, maybe we should encourage people not to file an issue but rather to fix it right away, and help in any way possible. In contrast, for things that affect the RTOS itself, build system, etc., we would let people file issues. I think that keeping track of issues, prioritized and categorized by sub-system and platform would be of benefit to many users. Attempt to fix every bug on every hardware configuration is not humanly possible. I think fixing bugs would have to be like committers responding to PRs: People will have have "scratch what itches" (or something like that). But just knowing that something has a bug is useful information to users. I dont know how github issues work but I know that in Jira, issues can be tagged with any number of "tags". Then you can filter by tags and see all issues with that tag. Utilizing this feature, we could have a tag for each supported MCU, and a tag for each supported board. When someone is thinking of using NuttX for their project with a particular board, they could look up the known issues and then make an informed decision if those issues might affect their project and, if so, if they are willing to scratch that itch and fix that issue. Then obviously what I said before no longer applies and we would encourage people to file issues provided they tag them correctly. I like that idea of tagging issues. That could prove very useful. Doesn't github support user-defined tags? I have never used them, but they seem a little primitive from what I have read. The issues in the top-level TODO list are not tagged, but grouped by functional areas and would be unusable if they were not so grouped. A long list of old ungrouped, untagged github issues would be similarly useless. I am not a big fan of selecting a tools then defining your management processes to match the tool. I prefer to think the other way around. I spent decades as as system engineer and system architect and I have top-down thinking in my bones. I really don't know anything of significance about Jira so it would be irresponsible for me to advocate anything either way. Github issues are great places for discussing current topics. I am more familiar with Bitbucket issues, and I assume they are similar. My experience is that if no one takes immediate action on an issue, it lingers, people lose interest, and the issue fades from group memory. Then years later they are there in the issue list, out of context, possibly inactionable. Issues are good for the immediate reactions to and dialog about an issue. But that doesn't it really constitutes management of issues. At one point Brennan demonstrated that you can link a Jira issue to a PR. I wonder... can you also link a Jira issue to a github issue. If so, then why not use both? Users could enter issues into Github, email, or Jirah. Github issues could support some dialog. Jira might then provide the missing project management component. And what do we do with the old issues still in the Bitbucket Issues? Or the issues in the TODO list. There are usually issues raised in emails on daily basis. Most of the time, these are worked out through through email exchanges, others are not and are just forgotten. Greg
Re: Bug tracking
On Fri, Jan 3, 2020 at 4:50 PM Gregory Nutt wrote: > > > Maybe people should not file a bug for hardware-specific issues that > > affect only their specific configuration. As you point out, it is > > unlikely that anyone else will be able to fix or test such an issue. > > So, for those cases, maybe we should encourage people not to file an > > issue but rather to fix it right away, and help in any way possible. > > > > In contrast, for things that affect the RTOS itself, build system, > > etc., we would let people file issues. > > I think that keeping track of issues, prioritized and categorized by > sub-system and platform would be of benefit to many users. Attempt to > fix every bug on every hardware configuration is not humanly possible. > I think fixing bugs would have to be like committers responding to PRs: > People will have have "scratch what itches" (or something like that). > But just knowing that something has a bug is useful information to users. I dont know how github issues work but I know that in Jira, issues can be tagged with any number of "tags". Then you can filter by tags and see all issues with that tag. Utilizing this feature, we could have a tag for each supported MCU, and a tag for each supported board. When someone is thinking of using NuttX for their project with a particular board, they could look up the known issues and then make an informed decision if those issues might affect their project and, if so, if they are willing to scratch that itch and fix that issue. Then obviously what I said before no longer applies and we would encourage people to file issues provided they tag them correctly. Nathan
Re: Bug tracking
Maybe people should not file a bug for hardware-specific issues that affect only their specific configuration. As you point out, it is unlikely that anyone else will be able to fix or test such an issue. So, for those cases, maybe we should encourage people not to file an issue but rather to fix it right away, and help in any way possible. In contrast, for things that affect the RTOS itself, build system, etc., we would let people file issues. I think that keeping track of issues, prioritized and categorized by sub-system and platform would be of benefit to many users. Attempt to fix every bug on every hardware configuration is not humanly possible. I think fixing bugs would have to be like committers responding to PRs: People will have have "scratch what itches" (or something like that). But just knowing that something has a bug is useful information to users.
Re: Bug tracking
Hi Nathan, On 1/3/20, Nathan Hartman wrote: > On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean > wrote: >> >> Re which tool to use, which one are your users likely to use. From >> >> previous discussion I don’t think many would have used git issues, but >> >> I’m not sure than many would be familiar with JIRA. >> > >> > The majority problem reports .. well over 90% ... are recieved via >> > email. Sometimes several today. If some knowledgeable person is >> > online, they may respond with some help. But most go unanswered because >> > no one has an answer to offer. >> >> Some projects ask user to create an issue (JIRA or GitHub) if it an >> actually bug rather than just helping with some setup or config issue. You >> might want to consider that. > > Maybe people should not file a bug for hardware-specific issues that > affect only their specific configuration. As you point out, it is > unlikely that anyone else will be able to fix or test such an issue. > So, for those cases, maybe we should encourage people not to file an > issue but rather to fix it right away, and help in any way possible. > > In contrast, for things that affect the RTOS itself, build system, > etc., we would let people file issues. > > Thoughts? > Well, I think an option is to suggest to people facing this issue to test on some reference board that more people could have and could duplicate the issue easily. We don't have an official reference board, but many people use the stm32f4discovery as I reference board. Also we need to have a page where people can see which features each arch/board has support. It will make their life easier and our as well, because they will know that such features is not working and will not open an issue. BR, Alan
Re: Bug tracking
On Fri, Jan 3, 2020 at 4:01 PM Justin Mclean wrote: > >> Re which tool to use, which one are your users likely to use. From > >> previous discussion I don’t think many would have used git issues, but I’m > >> not sure than many would be familiar with JIRA. > > > > The majority problem reports .. well over 90% ... are recieved via email. > > Sometimes several today. If some knowledgeable person is online, they may > > respond with some help. But most go unanswered because no one has an > > answer to offer. > > Some projects ask user to create an issue (JIRA or GitHub) if it an actually > bug rather than just helping with some setup or config issue. You might want > to consider that. Maybe people should not file a bug for hardware-specific issues that affect only their specific configuration. As you point out, it is unlikely that anyone else will be able to fix or test such an issue. So, for those cases, maybe we should encourage people not to file an issue but rather to fix it right away, and help in any way possible. In contrast, for things that affect the RTOS itself, build system, etc., we would let people file issues. Thoughts? Nathan
Re: Bug tracking
HI, >> Re which tool to use, which one are your users likely to use. From previous >> discussion I don’t think many would have used git issues, but I’m not sure >> than many would be familiar with JIRA. > > The majority problem reports .. well over 90% ... are recieved via email. > Sometimes several today. If some knowledgeable person is online, they may > respond with some help. But most go unanswered because no one has an answer > to offer. Some projects ask user to create an issue (JIRA or GitHub) if it an actually bug rather than just helping with some setup or config issue. You might want to consider that. Thanks, Justin
Re: Bug tracking
With many people on the PPMC taking responsibility for any issues that come in I don’t see that they would be ignored, unless the PPMC is not acting as a PPMC. Other committers and contributors can alas help out and that’s one way you grow your community and get more committers / PPMC members. Historically, that has been the case -- Issues are ignored. But that was only me managing the project. I think we can do better with a team. The issues tend to be very hardware specific to someone's particular MCU, particular driver, and particular board. Seldom are there broad systematic issues reported. There are issues reported in the repository issues lists only a few times per year, but that may also change. Re which tool to use, which one are your users likely to use. From previous discussion I don’t think many would have used git issues, but I’m not sure than many would be familiar with JIRA. The majority problem reports .. well over 90% ... are recieved via email. Sometimes several today. If some knowledgeable person is online, they may respond with some help. But most go unanswered because no one has an answer to offer.
Re: Bug tracking
Hi, > When you say that all the issue tracker(s) were ignored (and > eventually lost anyway), that indicates a deeper problem than just > choosing an issue tracking software. With many people on the PPMC taking responsibility for any issues that come in I don’t see that they would be ignored, unless the PPMC is not acting as a PPMC. Other committers and contributors can alas help out and that’s one way you grow your community and get more committers / PPMC members. Re which tool to use, which one are your users likely to use. From previous discussion I don’t think many would have used git issues, but I’m not sure than many would be familiar with JIRA. Thanks, Justin
Re: Bug tracking
When you say that all the issue tracker(s) were ignored (and eventually lost anyway), that indicates a deeper problem than just choosing an issue tracking software. Issues will be ignored if there is no process to management them. I think we need to first and foremost get input from our mentors. Secondly, perhaps we should look at what various established ASF projects are doing, and even go and talk to them on their dev lists to ask what, in addition to the issue tracker itself, methodology they have in place around that. Sounds good.
Re: Bug tracking
On Fri, Jan 3, 2020 at 9:45 AM Gregory Nutt wrote: > > The primary place that I keep issue is in the TODO list file in the > > nuttx/ top-level directory. That used to be a simple way for me to > > keep track of issues and has travel from CVS on SourceForge, to GIT on > > sourceforge, to Bitbucket (all issues were lost on each transition). > > It was simple because I could just edit a .txt file and commit it. > > > > But now the TODO list is not simple, it is not friendly, and it is not > > open. I can not longer modify the TODO list without submitting a > > pull-request. That is not worth the trouble (and I do have some issue > > updates that I want to make). We need a user-friendly, open, > > management, project-level, single-point bug tracking system ASAP. > The TODO list is not a solution either. It was also ignored. Nor are > github issues which will be ignored as well. The solution is a process > of project management. Any tool for managing the text of the issue can > be used. All will be ignored with no process. The particular software used for issue tracking isn't the important question here. Whether it's Jira, GitHub, BugZilla, Trac, a TODO file, or /*! \todo */ comments in the code, that's an implementation detail. When you say that all the issue tracker(s) were ignored (and eventually lost anyway), that indicates a deeper problem than just choosing an issue tracking software. I think we need to first and foremost get input from our mentors. Secondly, perhaps we should look at what various established ASF projects are doing, and even go and talk to them on their dev lists to ask what, in addition to the issue tracker itself, methodology they have in place around that. Nathan
Bug tracking
Has any decision been made wrt bug tracking? Brennan brought up Jira but many people complained about that and preferred git issues, I think because of inertia, not based on any logical reasons. We all love the tools that we know how to use. But I don't think that any project wide decision has been made. In the old bitbucket repositories, some people reported issues on the GIT repositories, but those were mostly just ignored. There was no process for dealing with the issues in place so most just lingered around for months or years before someone (me) finally got sick of seeing them and deleting them. So I think that just saying the Github issues is the solution is just sweeping things under the rug. I fully expect that github issues will be ignore just like bitbucket issues were. We need something more integrated with day-to-day project management to assure that someone is handling issues. Jira is a project management tool, but no one is a Jira expert. The primary place that I keep issue is in the TODO list file in the nuttx/ top-level directory. That used to be a simple way for me to keep track of issues and has travel from CVS on SourceForge, to GIT on sourceforge, to Bitbucket (all issues were lost on each transition). It was simple because I could just edit a .txt file and commit it. But now the TODO list is not simple, it is not friendly, and it is not open. I can not longer modify the TODO list without submitting a pull-request. That is not worth the trouble (and I do have some issue updates that I want to make). We need a user-friendly, open, management, project-level, single-point bug tracking system ASAP. Just saying Github issue is not a project level solution. It is just saying sweep the problems under the rug. Greg
