On Fri, May 27, 2011 at 12:53 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> Hi Stephen, Dan,
>
> On Fri, 27 May 2011 13:30:03 +1000, Stephen Rothwell wrote:
>> Today's linux-next merge of the async_tx tree got a conflict in
>> drivers/dma/dw_dmac.c between commit e05503ef1186 ("Haavard Skinnemoen
>> has left Atmel") from Linus' tree and commit aecb7b64dd9e
>> ("dmaengine/dw_dmac: Update maintainer-ship") from the async_tx tree.
>>
>> Just context changes. I fixed it up (see below) and can carry the fix as
>> necessary.
>
> Dan's patch is just plain wrong. MODULE_AUTHOR is about who wrote the
> code, not who maintains it. A change of maintainer should lead to an
> update or addition to file MAINTAINERS.
The patch in question did also update MAINTAINERS. Since Viresh has
done a good amount of work on the driver (top-developer by commits
since the initial merge) and likely cares about user reports (now that
he has stepped up to maintain it) is there a reason that he should not
have his own MODULE_AUTHOR line in the driver as well?
The real problem here is the late detection of the merge conflict. We
need to submit Vinod's git tree for inclusion in -next. Given the
relative patch traffic I think async_tx.git should come after
slave-dma.git in the merge order, and any reworks I do of the
non-slave case will be based on Vinod's baseline. We'll get this in
shape for the next cycle as I had to rebase things a bit when pulling
the current slave-dma.git tree.
> Thanks Viresh for stepping in, BTW, new maintainers are always welcome.
>
> (As a side note, the relevance of MODULE_AUTHOR given the development
> and maintenance model the Linux kernel has embraced can certainly be
> discussed, but that's a different story.)
We don't seem to have documentation around it, but making a bunch of
commits and stepping up to be a maintainer seems enough justification
to have your contact info show up in modinfo...
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
