Bug Tracking

[Gregory Nutt <sp...@gmail.com>]

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

[Nathan Hartman <ha...@gmail.com>]

On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt <sp...@gmail.com> 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

[Brennan Ashton <ba...@brennanashton.com>]

Can people also respond on the Projects feature of GitHub?

I imagined it would be used for thinks like new ports, releases, and large
features. Most of these would have tasks spanning two repos.

Take crypto. There is an OS interface component, at least a demo app, and
likely a configuration to be configured in testing. Do we open tickets in
the three and link them to one project in a single repo's Projects? Or do
we have three projects all called crypto each under each repos Projects?



Here is my vote:
JIRA or GitHub I don't care. But I would prefer a single issue tracker not
spanning multiple repos, although I would not vote against it if it came
down to it.

I would vote against multiple Projects, checking 5 boards to cut a release,
no thank you. I would also vote against using both GitHub and JIRA mixing
issue tracking and project management.

--Brennan

On Tue, Jan 14, 2020, 4:09 PM Nathan Hartman <ha...@gmail.com>
wrote:

> On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean <ju...@classsoftware.com>
> 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: [DISCUSS]Bug Tracking

[David Sidrane <Da...@nscdg.com>]

> 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:bashton@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 <Da...@nscdg.com>
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

[Alin Jerpelea <je...@gmail.com>]

 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 <sp...@gmail.com> 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

[Gregory Nutt <sp...@gmail.com>]

> 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

[Brennan Ashton <ba...@brennanashton.com>]

On Wed, Jan 15, 2020, 10:09 AM David Sidrane <Da...@nscdg.com>
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

[David Sidrane <Da...@nscdg.com>]

+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:spudaneco@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

[Gregory Nutt <sp...@gmail.com>]

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

[Gregory Nutt <sp...@gmail.com>]

> 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

[Justin Mclean <ju...@classsoftware.com>]

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

[Abdelatif Guettouche <ab...@gmail.com>]

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 <sp...@gmail.com> 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

[Gregory Nutt <sp...@gmail.com>]

> 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

[Brennan Ashton <ba...@brennanashton.com>]

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 <ju...@classsoftware.com>
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

[Justin Mclean <ju...@classsoftware.com>]

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

[Brennan Ashton <ba...@brennanashton.com>]

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 <ha...@gmail.com>
wrote:

> On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt <sp...@gmail.com> 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

[Nathan Hartman <ha...@gmail.com>]

On Tue, Jan 14, 2020 at 7:17 PM Gregory Nutt <sp...@gmail.com> 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

[Gregory Nutt <sp...@gmail.com>]

> 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

[Nathan Hartman <ha...@gmail.com>]

On Tue, Jan 14, 2020 at 6:32 PM Justin Mclean <ju...@classsoftware.com>
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

[Gregory Nutt <sp...@gmail.com>]

> 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

[Andrew Elder <an...@pobox.com>]

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 <sp...@gmail.com> 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

[Gregory Nutt <sp...@gmail.com>]

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

[Gregory Nutt <sp...@gmail.com>]

> 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: Bug Tracking

[Justin Mclean <ju...@classsoftware.com>]

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