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: [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.
