linux-next: manual merge of the async_tx tree with Linus' tree

linux-next: manual merge of the async_tx tree with Linus' tree

[Stephen Rothwell]

Hi Dan,

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.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/dma/dw_dmac.c
index 2a2e2fa,efd836d..0000000
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@@ -1486,4 -1575,5 +1575,5 @@@ module_exit(dw_exit)
  
  MODULE_LICENSE("GPL v2");
  MODULE_DESCRIPTION("Synopsys DesignWare DMA Controller driver");
 -MODULE_AUTHOR("Haavard Skinnemoen <haavard.skinnemoen@atmel.com>");
 +MODULE_AUTHOR("Haavard Skinnemoen (Atmel)");
+ MODULE_AUTHOR("Viresh Kumar <viresh.kumar@st.com>");

Re: linux-next: manual merge of the async_tx tree with Linus' tree

[Jean Delvare]

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.

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

-- 
Jean Delvare

Re: linux-next: manual merge of the async_tx tree with Linus' tree

[Dan Williams]

On Fri, May 27, 2011 at 12:53 AM, Jean Delvare <khali@linux-fr.org> 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

Re: linux-next: manual merge of the async_tx tree with Linus' tree

[Jean Delvare]

Hi Dan,

On Fri, 27 May 2011 12:08:37 -0700, Dan Williams wrote:
> On Fri, May 27, 2011 at 12:53 AM, Jean Delvare <khali@linux-fr.org> 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?

Sorry, I guess I shouldn't have commented on a driver I don't know
anything about. Furthermore, I didn't read the patch carefully, it is
adding a MODULE_AUTHOR, when I thought it was replacing it (in all
honestly I didn't even know it was possible to have more than one
MODULE_AUTHOR statement per driver.)

So really it's alright, just ignore me, and sorry for the noise.

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

My point is that the authors of a driver aren't necessarily the right
persons to contact in case of problem. Given that distribution users
won't find the MAINTAINERS file (and the files entries there point to
source files anyway), users don't have a proper way to find the right
contact. I suspect that driver authors are better located in the source
code (it is already there most of the time) and we'd rather need a
MODULE_MAINTAINER() macro, ideally generated automatically from
MAINTAINERS. But again it is a wider debate, not related with the
problem at hand.

-- 
Jean Delvare