[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 :-) -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core