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
