[yocto] Bug reporting and good bug reports

Trevor Woerner twoerner at gmail.com
Fri Jan 9 06:44:08 PST 2015


[If I reply, people will think that I'm really big on this MAINTAINERS
file thing, which I'm really not. But if I don't reply I'll feel as
though my point was missed :-(]

On 01/07/15 16:30, Richard Purdie wrote:
> On Wed, 2015-01-07 at 16:21 -0500, Trevor Woerner wrote:
>> On 01/07/15 04:25, Richard Purdie wrote:
>>> I also have a patch. Where should I share them? How do I ensure everyone
>>> with an interest in this defect actually gets the patch? Sure I can
>>> create email and send to the people who I think need to know.
>> When I went through that whole "let's add a MAINTAINERS file" thing last
>> year this is exactly what I had in mind at that time.
> But that isn't what I'm talking about.

Okay, sorry for going off-topic.

> I'm talking about people being able to say "I have some interest in a
> particular defect and I'd like updates about it". That is completely
> different to a MAINTAINERS file. The user and easily opt in to specific
> things using the web UI and its self maintaining to a large degree.

While, on the one hand, it would be nice for random people to say "I'm
interested in this defect, I'm going to add myself to the list of people
who are notified when something about this defect changes" (which, as
I'm trying to point out, is a use-case of the MAINTAINERS file), I
believe your more basic question of "I have a patch, who do I email it
to?" needs to be addressed as well.

At this point, we don't have much of a mechanism for people to figure
out who to email their patches to. Emailing one's patches to the right
people is a good thing since it'll increase the chances of it being
reviewed by the most relevant people, and every project could stand to
have more reviewers. What we have is a README file. But this mechanism
requires people to read the README file (which isn't always a given) and
follow its instructions (which is prone to various errors).

The MAINTAINERS file automates the process of figuring out who the
relevant people are to email your patches to. Not only can people add
themselves to the list for a given area of the project, but the
MAINTAINERS mechanism (i.e. the script) will also look at the git
history of the lines your patch is modifying and add those people to the
list as well (the assumption being the last person who modified the code
you're about to modify might be interested in what you're doing to their
code).

Can you email your patch to bugzilla? And have bugzilla figure out all
the people to forward your patch to? Not that I know of.

Do you expect people working on a bug they find in the code one random
day to go searching through bugzilla in case someone else has already
noticed this bug and filed a report so they can look at the bugzilla
issue's CC list to find out who to email the patch to?

If a developer starts their day by looking through bugzilla for an open
issue to fix (or is assigned such an issue from a manager) then your
workflow makes sense. They will prepare a patch, update the issue, and
then email the patch *hopefully* CC'ing the people in the bugzilla CC
list and/or updating the issue with a link to their patch submission.

But if a developer is working on their own thing and stumbles across
some bug, completely unaware that this has been reported in bugzilla,
they will prepare their patch and email it to the mailing list (and most
likely nobody else). At least the MAINTAINERS file would help a little
bit in this case (if for nothing else but to figure out which mailing
list to email!) and if people added themselves to the MAINTAINERS file
as being interested in a certain area, then those people would be
emailed too.

The biggest difference between what you're talking about and what I'm
talking about is the granularity. A bugzilla entry addresses a defect,
which could cross many files and layers. The granularity of the
MAINTAINERS file is more about individual files and directories.

Thanks for listening :-)



More information about the yocto mailing list