This updates the maintainer for virtio i2c drvier
Signed-off-by: Conghui <[email protected]>
Acked-by: Jian Jun Chen <[email protected]>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a8c8f6b42436..44747f4641a6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21920,7 +21920,7 @@ F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
VIRTIO I2C DRIVER
-M: Conghui Chen <[email protected]>
+M: Jian Jun Chen <[email protected]>
M: Viresh Kumar <[email protected]>
L: [email protected]
L: [email protected]
--
2.25.1
On 14-12-22, 13:36, Conghui wrote:
> This updates the maintainer for virtio i2c drvier
>
> Signed-off-by: Conghui <[email protected]>
> Acked-by: Jian Jun Chen <[email protected]>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a8c8f6b42436..44747f4641a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21920,7 +21920,7 @@ F: include/uapi/linux/virtio_snd.h
> F: sound/virtio/*
>
> VIRTIO I2C DRIVER
> -M: Conghui Chen <[email protected]>
> +M: Jian Jun Chen <[email protected]>
> M: Viresh Kumar <[email protected]>
> L: [email protected]
> L: [email protected]
Wolfram,
I understand that it is okay to pass the maintainership, within the
company, for platform specific parts from one person to another, since
they have the best knowledge of the code and are the only one
interested in maintaining it too.
But what is the rule for generic drivers like this one ?
--
viresh
Hi Viresh,
> I understand that it is okay to pass the maintainership, within the
> company, for platform specific parts from one person to another, since
> they have the best knowledge of the code and are the only one
> interested in maintaining it too.
>
> But what is the rule for generic drivers like this one ?
Dunno if this is really a rule, but if a maintainer steps out and makes
sure there is someone to pick up the work, this is more than welcome.
Way better than a stale entry in the MAINTAINERS file.
I mean, it does not limit the chance to have further maintainers, for
example. I believe in meritocracy here. Those who do and collaborate,
shall get responsibility. If not, then not. We can fix this, too, if
needed.
What is the reason for your question?
All the best,
Wolfram
On 14-12-22, 11:20, Wolfram Sang wrote:
> Dunno if this is really a rule, but if a maintainer steps out and makes
> sure there is someone to pick up the work, this is more than welcome.
> Way better than a stale entry in the MAINTAINERS file.
Sure, a stale entry is always bad.
> I mean, it does not limit the chance to have further maintainers, for
> example. I believe in meritocracy here. Those who do and collaborate,
> shall get responsibility. If not, then not. We can fix this, too, if
> needed.
>
> What is the reason for your question?
It was a general question that I asked myself and didn't know an
answer to. I wasn't sure if adding someone to be a maintainer here to
a driver, which they haven't contributed to until now (at least based
on open source commits), is right or not, since this isn't a stale
entry in MAINTAINERS anyway.
An entry as R: would be okay normally IMO, as this makes sure
interested party is kept aware of the development in the area. An M:
entry somehow gives a higher level of authority to the person and
without any prior contributions, it feels tricky at least.
Anyway, I don't have any objection to the patch at least as it was
primarily developed by Intel engineers.
Acked-by: Viresh Kumar <[email protected]>
--
viresh
On Wed, Dec 14, 2022 at 01:36:31PM +0800, Conghui wrote:
> This updates the maintainer for virtio i2c drvier
I got that, but what is going on here exactly?
I generally expect a new maintainer to be active in the
project for a while first.
I don't see contributions or reviews for this driver or
for that matter for any virtio or i2c drivers from Jian Jun Chen.
It looks like you are no longer interested in maintaining
this? In that case pls just send a patch removing yourself.
Jian Jun Chen, if you are interested in reviewing
patches please start doing so, you don't need to
be listed as a maintainer for this to happen.
Once you do this for a while and write some patches,
you can become a maintainer, this is not a high bar
to clear.
> Signed-off-by: Conghui <[email protected]>
> Acked-by: Jian Jun Chen <[email protected]>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a8c8f6b42436..44747f4641a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21920,7 +21920,7 @@ F: include/uapi/linux/virtio_snd.h
> F: sound/virtio/*
>
> VIRTIO I2C DRIVER
> -M: Conghui Chen <[email protected]>
> +M: Jian Jun Chen <[email protected]>
> M: Viresh Kumar <[email protected]>
> L: [email protected]
> L: [email protected]
> --
> 2.25.1
On Wed, Dec 14, 2022 at 11:20:34AM +0100, Wolfram Sang wrote:
> Hi Viresh,
>
> > I understand that it is okay to pass the maintainership, within the
> > company, for platform specific parts from one person to another, since
> > they have the best knowledge of the code and are the only one
> > interested in maintaining it too.
> >
> > But what is the rule for generic drivers like this one ?
>
> Dunno if this is really a rule, but if a maintainer steps out and makes
> sure there is someone to pick up the work, this is more than welcome.
> Way better than a stale entry in the MAINTAINERS file.
>
> I mean, it does not limit the chance to have further maintainers, for
> example. I believe in meritocracy here. Those who do and collaborate,
> shall get responsibility.
Exactly. I'd like to see Jian Jun Chen do and collaborate first.
> If not, then not. We can fix this, too, if
> needed.
>
> What is the reason for your question?
>
> All the best,
>
> Wolfram
>
On Wed, Dec 14, 2022 at 04:26:42PM +0530, Viresh Kumar wrote:
> On 14-12-22, 11:20, Wolfram Sang wrote:
> > Dunno if this is really a rule, but if a maintainer steps out and makes
> > sure there is someone to pick up the work, this is more than welcome.
> > Way better than a stale entry in the MAINTAINERS file.
>
> Sure, a stale entry is always bad.
>
> > I mean, it does not limit the chance to have further maintainers, for
> > example. I believe in meritocracy here. Those who do and collaborate,
> > shall get responsibility. If not, then not. We can fix this, too, if
> > needed.
> >
> > What is the reason for your question?
>
> It was a general question that I asked myself and didn't know an
> answer to. I wasn't sure if adding someone to be a maintainer here to
> a driver, which they haven't contributed to until now (at least based
> on open source commits), is right or not, since this isn't a stale
> entry in MAINTAINERS anyway.
>
> An entry as R: would be okay normally IMO, as this makes sure
> interested party is kept aware of the development in the area. An M:
> entry somehow gives a higher level of authority to the person and
> without any prior contributions, it feels tricky at least.
>
> Anyway, I don't have any objection to the patch at least as it was
> primarily developed by Intel engineers.
>
> Acked-by: Viresh Kumar <[email protected]>
If a maintainer acks a patch I generally expect that the patch is good.
If we have a maintainer who's not familiar with the codebase, this
assumption does not hold.
R: would be ok with me.
> --
> viresh
On 12/14/2022 20:00, Michael S. Tsirkin wrote:
> On Wed, Dec 14, 2022 at 11:20:34AM +0100, Wolfram Sang wrote:
>> Hi Viresh,
>>
>>> I understand that it is okay to pass the maintainership, within the
>>> company, for platform specific parts from one person to another, since
>>> they have the best knowledge of the code and are the only one
>>> interested in maintaining it too.
>>>
>>> But what is the rule for generic drivers like this one ?
>> Dunno if this is really a rule, but if a maintainer steps out and makes
>> sure there is someone to pick up the work, this is more than welcome.
>> Way better than a stale entry in the MAINTAINERS file.
>>
>> I mean, it does not limit the chance to have further maintainers, for
>> example. I believe in meritocracy here. Those who do and collaborate,
>> shall get responsibility.
> Exactly. I'd like to see Jian Jun Chen do and collaborate first.
Hi Michael,
Sure, I will start to collaborate first.
>> If not, then not. We can fix this, too, if
>> needed.
>>
>> What is the reason for your question?
>>
>> All the best,
>>
>> Wolfram
>>
>
On 12/14/2022 19:37, Michael S. Tsirkin wrote:
> On Wed, Dec 14, 2022 at 01:36:31PM +0800, Conghui wrote:
>> This updates the maintainer for virtio i2c drvier
> I got that, but what is going on here exactly?
> I generally expect a new maintainer to be active in the
> project for a while first.
> I don't see contributions or reviews for this driver or
> for that matter for any virtio or i2c drivers from Jian Jun Chen.
> It looks like you are no longer interested in maintaining
> this? In that case pls just send a patch removing yourself.
>
> Jian Jun Chen, if you are interested in reviewing
> patches please start doing so, you don't need to
> be listed as a maintainer for this to happen.
> Once you do this for a while and write some patches,
> you can become a maintainer, this is not a high bar
> to clear.
Hi Michael,
Yes. I am interested in the virtio I2C maintenance. I have lots of
virtio experience in ACRN device model development and was involved in
the early phase virtio I2C discussion in ACRN before Jie/Conghui
upstream the virtio I2C spec. Sure, I will start to collaborate first.
>> Signed-off-by: Conghui <[email protected]>
>> Acked-by: Jian Jun Chen <[email protected]>
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a8c8f6b42436..44747f4641a6 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -21920,7 +21920,7 @@ F: include/uapi/linux/virtio_snd.h
>> F: sound/virtio/*
>>
>> VIRTIO I2C DRIVER
>> -M: Conghui Chen <[email protected]>
>> +M: Jian Jun Chen <[email protected]>
>> M: Viresh Kumar <[email protected]>
>> L: [email protected]
>> L: [email protected]
>> --
>> 2.25.1
On Tue, Dec 27, 2022 at 12:04:10PM +0800, Chen, Jian Jun wrote:
>
> On 12/14/2022 19:37, Michael S. Tsirkin wrote:
> > On Wed, Dec 14, 2022 at 01:36:31PM +0800, Conghui wrote:
> > > This updates the maintainer for virtio i2c drvier
> > I got that, but what is going on here exactly?
> > I generally expect a new maintainer to be active in the
> > project for a while first.
> > I don't see contributions or reviews for this driver or
> > for that matter for any virtio or i2c drivers from Jian Jun Chen.
> > It looks like you are no longer interested in maintaining
> > this? In that case pls just send a patch removing yourself.
> >
> > Jian Jun Chen, if you are interested in reviewing
> > patches please start doing so, you don't need to
> > be listed as a maintainer for this to happen.
> > Once you do this for a while and write some patches,
> > you can become a maintainer, this is not a high bar
> > to clear.
>
> Hi Michael,
>
> Yes. I am interested in the virtio I2C maintenance. I have lots of virtio
> experience in ACRN device model development and was involved in the early
> phase virtio I2C discussion in ACRN before Jie/Conghui upstream the virtio
> I2C spec. Sure, I will start to collaborate first.
Excellent, thanks a lot!
> > > Signed-off-by: Conghui <[email protected]>
> > > Acked-by: Jian Jun Chen <[email protected]>
> > > ---
> > > MAINTAINERS | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index a8c8f6b42436..44747f4641a6 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -21920,7 +21920,7 @@ F: include/uapi/linux/virtio_snd.h
> > > F: sound/virtio/*
> > > VIRTIO I2C DRIVER
> > > -M: Conghui Chen <[email protected]>
> > > +M: Jian Jun Chen <[email protected]>
> > > M: Viresh Kumar <[email protected]>
> > > L: [email protected]
> > > L: [email protected]
> > > --
> > > 2.25.1
On Tue, Dec 27, 2022 at 12:05:09PM +0800, Chen, Jian Jun wrote:
>
> On 12/14/2022 20:00, Michael S. Tsirkin wrote:
> > On Wed, Dec 14, 2022 at 11:20:34AM +0100, Wolfram Sang wrote:
> > > Hi Viresh,
> > >
> > > > I understand that it is okay to pass the maintainership, within the
> > > > company, for platform specific parts from one person to another, since
> > > > they have the best knowledge of the code and are the only one
> > > > interested in maintaining it too.
> > > >
> > > > But what is the rule for generic drivers like this one ?
> > > Dunno if this is really a rule, but if a maintainer steps out and makes
> > > sure there is someone to pick up the work, this is more than welcome.
> > > Way better than a stale entry in the MAINTAINERS file.
> > >
> > > I mean, it does not limit the chance to have further maintainers, for
> > > example. I believe in meritocracy here. Those who do and collaborate,
> > > shall get responsibility.
> > Exactly. I'd like to see Jian Jun Chen do and collaborate first.
>
> Hi Michael,
>
> Sure, I will start to collaborate first.
Great!
> > > If not, then not. We can fix this, too, if
> > > needed.
> > >
> > > What is the reason for your question?
> > >
> > > All the best,
> > >
> > > Wolfram
> > >
> >