Tentative Agenda for the November workshop

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance,
etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

For those whose name is behind a topic: please prepare something before the meeting.

We have currently 17 or 18 attendees of a maximum of 25, so there is room for a few more people.

Hello,

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance,
etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

-----Original Message-----
From: [email protected] [mailto:media-workshop- [email protected]] On Behalf Of Sylwester Nawrocki
Sent: Monday, October 22, 2012 12:53 PM
To: Laurent Pinchart
Cc: [email protected]; linux-media
Subject: Re: [media-workshop] Tentative Agenda for the November workshop

Hi Laurent,

Quoted 6 lines · Laurent Pinchart

Hello,

Quoted 3 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8,

2012.

Quoted 9 lines

Quoted 3 lines

If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 3 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers,

both for

Quoted 11 lines

Quoted 10 lines

staging and mainline acceptance: which frameworks to use,
v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

--
Regards,
Sylwester

_______________________________________________
media-workshop mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop

Hi all,

Could someone summaries very rapidly what is this create/select context stuff ? For now I do not plan to be in Barcelona more than 1 day but at the same time don't want to miss something that might be useful for us.

Quoted 26 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 15 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for

staging and mainline acceptance: which frameworks to use, v4l2-compliance,

etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Hi Sylwester,

Quoted 31 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 29 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 8 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for

staging and mainline acceptance: which frameworks to use, v4l2-compliance,

Quoted 7 lines

etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

Quoted 4 lines

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

Quoted 37 lines · On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:

Quoted 35 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 25 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 6 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance,

Quoted 8 lines

etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Quoted 3 lines

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

I would be, but the problem is that the conference is also interesting.

The only day I have really available is the Friday *after* the summit.

Quoted 38 lines · On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:

Quoted 37 lines · On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:

Quoted 35 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 25 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 6 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance,

Quoted 8 lines

etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Quoted 5 lines

Quoted 3 lines

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

I would be, but the problem is that the conference is also interesting.

More interesting than a brainstorming session about hardware contexts ? ;-) There's of course talks I want to attend, but I can probably skip some of them.

Quoted 1 line

The only day I have really available is the Friday *after* the summit.

We'll probably need several brainstorming sessions anyway. I'd like to organize one before the media summit though, as we'll have limited time to discuss the topic during the summit, which doesn't suit brainstorming sessions very well.

Quoted 47 lines · On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:

Quoted 36 lines · On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:

Quoted 35 lines · On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:

Quoted 33 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 23 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 4 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which

Quoted 8 lines

frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Quoted 5 lines

Quoted 3 lines

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

I would be, but the problem is that the conference is also interesting.

More interesting than a brainstorming session about hardware contexts ? ;-) There's of course talks I want to attend, but I can probably skip some of them.

Quoted 6 lines

Quoted 1 line

The only day I have really available is the Friday *after* the summit.

We'll probably need several brainstorming sessions anyway. I'd like to organize one before the media summit though, as we'll have limited time to discuss the topic during the summit, which doesn't suit brainstorming sessions very well.

Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session.

Do you think we should do a half-day or a full day session on this?

Quoted 50 lines · On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:

Quoted 49 lines · On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:

Quoted 36 lines · On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:

Quoted 35 lines · On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:

Quoted 33 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 23 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 4 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which

Quoted 8 lines

frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 3 lines

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Quoted 5 lines

Quoted 3 lines

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

I would be, but the problem is that the conference is also interesting.

More interesting than a brainstorming session about hardware contexts ? ;-) There's of course talks I want to attend, but I can probably skip some of them.

Quoted 1 line

The only day I have really available is the Friday *after* the summit.

Quoted 8 lines

Quoted 4 lines

We'll probably need several brainstorming sessions anyway. I'd like to organize one before the media summit though, as we'll have limited time to discuss the topic during the summit, which doesn't suit brainstorming sessions very well.

Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session.

Quoted 1 line

Do you think we should do a half-day or a full day session on this?

Half a day should be more than enough to start with. The topic is quite complex, and we'll need to sleep over it, several times. A full day would just result in brain overheat. I was thinking more in the line of starting our thought process, so maybe twice an hour or two hours would be good. That would allow us to attend the ELCE talks as well :-) (there's definitely a couple of them that I would like to listen to).

Quoted 56 lines · Laurent Pinchart

Quoted 55 lines · On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote:

Quoted 54 lines · On Tue October 23 2012 03:03:35 Laurent Pinchart wrote:

Quoted 41 lines · On Monday 22 October 2012 14:06:06 Hans Verkuil wrote:

Quoted 40 lines · On Mon October 22 2012 13:18:46 Laurent Pinchart wrote:

Quoted 38 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 23 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 13 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?)

drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)

- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test

(Mauro/Samsung)

Quoted 8 lines

Quoted 4 lines

- Device tree support (Guennadi, not known yet whether this topic

is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

Quoted 5 lines

Quoted 3 lines

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

I would be, but the problem is that the conference is also interesting.

More interesting than a brainstorming session about hardware contexts ? ;-) There's of course talks I want to attend, but I can probably skip some of them.

Quoted 1 line

The only day I have really available is the Friday *after* the summit.

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

We'll probably need several brainstorming sessions anyway. I'd like to organize one before the media summit though, as we'll have limited time to discuss the topic during the summit, which doesn't suit brainstorming sessions very well.

Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session.

Kamil has presentation on Tuesday so there would be only Monday left.

Quoted 8 lines

Quoted 1 line

Do you think we should do a half-day or a full day session on this?

Half a day should be more than enough to start with. The topic is quite complex, and we'll need to sleep over it, several times. A full day would just result in brain overheat. I was thinking more in the line of starting our thought process, so maybe twice an hour or two hours would be good. That would allow us to attend the ELCE talks as well :-) (there's definitely a couple of them that I would like to listen to).

I agree, I wouldn't like to loose whole day of the conference for that as well. One, two hours for the starters could be sufficient. So we can possibly agree on some initial idea and could get back to it later. I don't think I have already material for a full day session.

Quoted 15 lines

Quoted 3 lines

Quoted 3 lines

Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session.

Kamil has presentation on Tuesday so there would be only Monday left.

Quoted 8 lines

Quoted 1 line

Do you think we should do a half-day or a full day session on this?

Half a day should be more than enough to start with. The topic is quite complex, and we'll need to sleep over it, several times. A full day would just result in brain overheat. I was thinking more in the line of starting our thought process, so maybe twice an hour or two hours would be good. That would allow us to attend the ELCE talks as well :-) (there's definitely a couple of them that I would like to listen to).

Quoted 4 lines

I agree, I wouldn't like to loose whole day of the conference for that as well. One, two hours for the starters could be sufficient. So we can possibly agree on some initial idea and could get back to it later. I don't think I have already material for a full day session.

One hour, possibly twice, would have my preference. That shouldn't be too difficult to organize. When will you and Kamil arrive ?

Hi Laurent,

Quoted 20 lines · Laurent Pinchart

Quoted 19 lines

Quoted 3 lines

Quoted 3 lines

Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session.

Kamil has presentation on Tuesday so there would be only Monday left.

Quoted 8 lines

Quoted 1 line

Do you think we should do a half-day or a full day session on this?

Half a day should be more than enough to start with. The topic is quite complex, and we'll need to sleep over it, several times. A full day would just result in brain overheat. I was thinking more in the line of starting our thought process, so maybe twice an hour or two hours would be good. That would allow us to attend the ELCE talks as well :-) (there's definitely a couple of them that I would like to listen to).

I agree, I wouldn't like to loose whole day of the conference for that as well. One, two hours for the starters could be sufficient. So we can possibly agree on some initial idea and could get back to it later. I don't think I have already material for a full day session.

Quoted 2 lines

One hour, possibly twice, would have my preference. That shouldn't be too difficult to organize. When will you and Kamil arrive ?

Sounds good to me. We'll arrive on Sunday afternoon, and staying until next Sunday.

Hi Sylwester,

Quoted 31 lines · On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote:

Quoted 29 lines · Laurent Pinchart

Quoted 6 lines · On Monday 22 October 2012 10:35:56 Hans Verkuil wrote:

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you Hans for taking care of the agenda.

Quoted 8 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for

staging and mainline acceptance: which frameworks to use, v4l2-compliance,

Quoted 7 lines

etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ?

Quoted 4 lines

My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic.

A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ?

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)

- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

For those whose name is behind a topic: please prepare something before the meeting.

We have currently 17 or 18 attendees of a maximum of 25, so there is room for a few more people.

Regards,

Hans

_______________________________________________
media-workshop mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop

Quoted 6 lines · Hans Verkuil

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Quoted 9 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)

+ asynchronous probing, I guess. It's probably implicitly included though.

Quoted 9 lines

- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

For those whose name is behind a topic: please prepare something before the meeting.

We have currently 17 or 18 attendees of a maximum of 25, so there is room for a few more people.

Quoted 9 lines

Regards,

Hans

_______________________________________________
media-workshop mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Hi all

Quoted 18 lines · Guennadi Liakhovetski

Quoted 15 lines · Hans Verkuil

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)

Quoted 1 line

+ asynchronous probing, I guess. It's probably implicitly included though.

As the meeting approaches, it would be good to have a decision - do we want to discuss DT / async or not? My flights this time are not quite long enough to prepare for the discussion on them;-)

Quoted 25 lines · On Wed October 31 2012 14:12:05 Guennadi Liakhovetski wrote:

Quoted 23 lines · Guennadi Liakhovetski

Quoted 13 lines · Hans Verkuil

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)

Quoted 6 lines

- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)

+ asynchronous probing, I guess. It's probably implicitly included though.

Quoted 3 lines

As the meeting approaches, it would be good to have a decision - do we want to discuss DT / async or not? My flights this time are not quite long enough to prepare for the discussion on them;-)

Looking at the current discussions I think discussing possible async solutions would be very useful. The DT implementation itself seems to be OK, at least I haven't seen any big discussions regarding that.

Quoted 30 lines · On Thursday 01 November 2012 17:01:02 Hans Verkuil wrote:

Quoted 28 lines · On Wed October 31 2012 14:12:05 Guennadi Liakhovetski wrote:

Quoted 21 lines · Guennadi Liakhovetski

Quoted 13 lines · Hans Verkuil

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)

Quoted 6 lines

- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)

Quoted 2 lines

+ asynchronous probing, I guess. It's probably implicitly included though.

As the meeting approaches, it would be good to have a decision - do we want to discuss DT / async or not? My flights this time are not quite long enough to prepare for the discussion on them;-)

Quoted 3 lines

Looking at the current discussions I think discussing possible async solutions would be very useful. The DT implementation itself seems to be OK, at least I haven't seen any big discussions regarding that.

Agreed.

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

Quoted 39 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

Quoted 4 lines

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

A MAINTAINERS entry should probably be required as well for new drivers.

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)

	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
	grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
	grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)

	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
	grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
	grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

i2c/tvp5150.ko = i2c/tvp5150.c

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c

usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c
usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c

usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c

Regards,

Hans

Quoted 146 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 115 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 28 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 27 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil
<[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012.
If you have additional things that you want to discuss, or
something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 13 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of
hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind
being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
	Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's
author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers,
even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)

	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
	grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
	grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e 

v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort

Quoted 1 line

without_maint

I excluded the core files from the list, as they don't need any
specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff
below that I can myself be added as "Odd fixes". Yet, I would very
much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

i2c/tvp5150.ko = i2c/tvp5150.c

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c

usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c
usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c

usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c

Regards,

Hans

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 11 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

Quoted 4 lines

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

Hi Mauro, Hans, all,

Quoted 215 lines · Mauro Carvalho Chehab

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 16 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

Quoted 2 lines

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future.

Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ?

I
mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can.

I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here..

And i'm also ready to maintain driver radio-ma901.c. I posted patches for this device about two weeks ago. Driver is rather small (first working version) but i hope to add more features there in future.

Best regards and wishes,
Alexey Klimov

Hi Mauro, Hans, all,

Quoted 211 lines · Mauro Carvalho Chehab

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 11 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

Quoted 6 lines

Quoted 4 lines

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future.

Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ? I mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can.

I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here..

And i'm also ready to maintain driver radio-ma901.c. I posted patches for this device about two weeks ago. Driver is rather small (first working version) but i hope to add more features there in future.

Hi Alexey,

Quoted 226 lines · On Mon November 12 2012 19:41:57 Alexey Klimov wrote:

Hi Mauro, Hans, all,

Quoted 211 lines · Mauro Carvalho Chehab

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 11 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

Quoted 6 lines

Quoted 4 lines

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future.

Quoted 8 lines

Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ? I mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can.

I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 or si470x. Do you want to be the maintainer for those two, or shall I add myself as the 'Odd Fixes' entry? I have hardware for both.

Quoted 2 lines

I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here..

I wrote the driver for that one, so I'll be the maintainer for this driver (I'm preparing MAINTAINERS patches as I write this).

Quoted 3 lines

And i'm also ready to maintain driver radio-ma901.c. I posted patches for this device about two weeks ago. Driver is rather small (first working version) but i hope to add more features there in future.

I missed this post, I'll try to do a quick review today.

Did you run v4l2-compliance on this driver? If not, then you should do that (v4l2-compliance -r /dev/radioX) and fix any errors it produces.

Regards,

Hans

Hi Hans,

Quoted 238 lines · Hans Verkuil

Hi Alexey,

Quoted 226 lines · On Mon November 12 2012 19:41:57 Alexey Klimov wrote:

Hi Mauro, Hans, all,

Quoted 211 lines · Mauro Carvalho Chehab

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 11 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

Quoted 6 lines

Quoted 4 lines

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future.

Quoted 8 lines

Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ? I mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can.

Quoted 3 lines

I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 or si470x. Do you want to be the maintainer for those two, or shall I add myself as the 'Odd Fixes' entry? I have hardware for both.

About si470x. It consists of two parts (usb and i2c interfaces) if i remember correctly.
I have kworld fm700 usb radio only. I saw platforms with radio-si470x-i2c but never had chances to play with it. May be it's also better to ask Tobias and Joonyoung Shim. I don't think that i'm ready to maintain si470x driver but i'll be happy to be up to date with any changes and discussions about all usb radio drivers.

I have usb gemtek radio 21 (dsbr100) and i'm ready to maintain it. I can prepare patch.
Also i think that only fixes and corrections will be present for this driver in future.

Quoted 6 lines

Quoted 3 lines

I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here..

I wrote the driver for that one, so I'll be the maintainer for this driver (I'm preparing MAINTAINERS patches as I write this).

Oh, i never mean to take maintainership on keene radio (you're the author) :) I just thought how to buy it.

Quoted 245 lines · On Mon 26 November 2012 00:18:30 Alexey Klimov wrote:

Hi Hans,

Quoted 238 lines · Hans Verkuil

Hi Alexey,

Quoted 226 lines · On Mon November 12 2012 19:41:57 Alexey Klimov wrote:

Hi Mauro, Hans, all,

Quoted 211 lines · Mauro Carvalho Chehab

Em Fri, 2 Nov 2012 14:47:49 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 157 lines · On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote:

Quoted 142 lines

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 113 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 26 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 25 lines

Hi Hans,

Em Mon, 22 Oct 2012 10:35:56 +0200
Hans Verkuil <[email protected]> escreveu:

Quoted 5 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 11 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed)
- Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:

     Supported:   Someone is actually paid to look after this.
     Maintained:  Someone actually looks after it.
     Odd Fixes:   It has a maintainer but they don't have time to do

much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 44 lines

Quoted 43 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

      $ git show --pretty=email|./scripts/get_maintainer.pl
      Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%)
      Hans Verkuil <[email protected]> (commit_signer:4/7=57%)
      Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
      Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
      Hans de Goede <[email protected]> (commit_signer:1/7=14%)
      [email protected] (open list:MEDIA INPUT INFRA...)
      [email protected] (open list)

According with this driver's copyrights:

* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. *
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

    DIR=$(dirname $0)

    $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
    grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
    grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

Quoted 6 lines

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Regards,
Mauro

These two are 'Supported' by me:

i2c/ad9389b.ko = i2c/ad9389b.c
i2c/adv7604.ko = i2c/adv7604.c

These are 'Maintained' by me:

Quoted 7 lines

i2c/cx2341x.ko                 = i2c/cx2341x.c
parport/bw-qcam.ko             = parport/bw-qcam.c
parport/c-qcam.ko              = parport/c-qcam.c
radio/dsbr100.ko               = radio/dsbr100.c
radio/radio-cadet.ko           = radio/radio-cadet.c
radio/radio-isa.ko             = radio/radio-isa.c
radio/radio-keene.ko           = radio/radio-keene.c

OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file.

Quoted 21 lines

There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo.

I can do 'Odd fixes' for the following:

i2c/cx25840/cx25840.ko         = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c
i2c/m52790.ko                  = i2c/m52790.c
i2c/msp3400.ko                 = i2c/msp3400-driver.c i2c/msp3400-kthreads.c
i2c/saa6588.ko                 = i2c/saa6588.c
i2c/saa7110.ko                 = i2c/saa7110.c
i2c/saa7115.ko                 = i2c/saa7115.c
i2c/saa7127.ko                 = i2c/saa7127.c
i2c/saa717x.ko                 = i2c/saa717x.c
i2c/tda7432.ko                 = i2c/tda7432.c
i2c/tda9840.ko                 = i2c/tda9840.c
i2c/tea6415c.ko                = i2c/tea6415c.c
i2c/tea6420.ko                 = i2c/tea6420.c
i2c/tvaudio.ko                 = i2c/tvaudio.c
i2c/tveeprom.ko                = i2c/tveeprom.c

Quoted 1 line

i2c/tvp5150.ko = i2c/tvp5150.c

While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver.

Quoted 11 lines

i2c/wm8739.ko                  = i2c/wm8739.c
i2c/wm8775.ko                  = i2c/wm8775.c
parport/pms.ko                 = parport/pms.c
platform/vivi.ko               = platform/vivi.c
radio/radio-aimslab.ko         = radio/radio-aimslab.c
radio/radio-gemtek.ko          = radio/radio-gemtek.c
radio/radio-maxiradio.ko       = radio/radio-maxiradio.c
radio/radio-miropcm20.ko       = radio/radio-miropcm20.c
radio/radio-mr800.ko           = radio/radio-mr800.c
radio/radio-rtrack2.ko         = radio/radio-rtrack2.c
radio/radio-si4713.ko          = radio/radio-si4713.c

Quoted 6 lines

Quoted 4 lines

usb/cx231xx/cx231xx-alsa.ko    = usb/cx231xx/cx231xx-audio.c
usb/cx231xx/cx231xx-dvb.ko     = usb/cx231xx/cx231xx-dvb.c
usb/cx231xx/cx231xx-input.ko   = usb/cx231xx/cx231xx-input.c
usb/cx231xx/cx231xx.ko         = +

I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status.

I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future.

Quoted 8 lines

Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ? I mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can.

Quoted 3 lines

I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 or si470x. Do you want to be the maintainer for those two, or shall I add myself as the 'Odd Fixes' entry? I have hardware for both.

Quoted 8 lines

About si470x. It consists of two parts (usb and i2c interfaces) if i remember correctly.
I have kworld fm700 usb radio only. I saw platforms with radio-si470x-i2c but never had chances to play with it. May be it's also better to ask Tobias and Joonyoung Shim. I don't think that i'm ready to maintain si470x driver but i'll be happy to be up to date with any changes and discussions about all usb radio drivers.

I'm happy to maintain the usb part and do odd-fixes for the i2c part for this driver...

Quoted 4 lines

I have usb gemtek radio 21 (dsbr100) and i'm ready to maintain it. I can prepare patch.
Also i think that only fixes and corrections will be present for this driver in future.

...and if you can maintain this driver, then we've split it up nicely.

Is that OK with you?

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here..

I wrote the driver for that one, so I'll be the maintainer for this driver (I'm preparing MAINTAINERS patches as I write this).

Oh, i never mean to take maintainership on keene radio (you're the author) :) I just thought how to buy it.

It's hard to get outside the UK. I had to use a forwarding service to get mine from amazon.co.uk.

Regards,

Hans

Em Thu, 1 Nov 2012 14:12:44 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

Quoted 3 lines

Em Thu, 1 Nov 2012 16:44:50 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 3 lines

Quoted 3 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

Quoted 50 lines

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:

S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain
to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 17 lines

Quoted 17 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 6 lines

Quoted 2 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)

	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers
	grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained
	grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab escreveu:

Quoted 111 lines

Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil escreveu:

Quoted 25 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 24 lines

Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil escreveu:

Quoted 7 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012.
If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Thank you for taking care of it.

Quoted 12 lines

- Explain current merging process (Mauro)
- Open floor for discussions on how to improve it (Mauro)
- Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil)
- V4L2 ambiguities (Hans Verkuil)
- TSMux device (a mux rather than a demux): Alain Volmat
- dmabuf status, esp. with regards to being able to test (Mauro/Samsung)
- Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available)

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 5 lines

Quoted 5 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

Quoted 8 lines

Quoted 3 lines

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:
S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

(btw, I just realized that I should be changing the EDAC drivers I maintain to Supported; the media drivers I maintain should be kept as Maintained).

I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes".

Quoted 45 lines

Quoted 44 lines

There are some issues by not having a MAINTAINERS entry:
- patches may not flow into the driver maintainer;
- patches will likely be applied without tests/reviews or may stay for a long time queued;
- ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1].

[1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer.

An example of this is the results for a patch I just applied

(changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced):

	$ git show --pretty=email|./scripts/get_maintainer.pl
	Mauro Carvalho Chehab <[email protected]> (maintainer:MEDIA INPUT
	INFRA...,commit_signer:7/7=100%) Hans Verkuil
	<[email protected]> (commit_signer:4/7=57%)
	Anatolij Gustschin <[email protected]> (commit_signer:1/7=14%)
	Wei Yongjun <[email protected]> (commit_signer:1/7=14%)
	Hans de Goede <[email protected]> (commit_signer:1/7=14%)
	[email protected] (open list:MEDIA INPUT INFRA...)
	[email protected] (open list)

According with this driver's copyrights:
* Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
*
* Freescale VIU video driver
*
* Authors: Hongjun Chen <[email protected]>
* Porting to 2.6.35 by DENX Software Engineering,
* Anatolij Gustschin <[email protected]>

The driver author (Hongjun Chen <[email protected]>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%.

This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series.

Quoted 7 lines

Quoted 3 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)

	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module

Quoted 1 line

/tmp/all_drivers grep drivers/media/ MAINTAINERS | perl -ne

's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

Quoted 10 lines · On Friday 02 November 2012 11:13:10 Mauro Carvalho Chehab wrote:

Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab escreveu:

Quoted 9 lines

Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil escreveu:

Quoted 8 lines · On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:

Quoted 7 lines

Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil escreveu:

Quoted 6 lines

Hi all,

This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list.

Quoted 33 lines

Quoted 33 lines

Quoted 4 lines

Quoted 2 lines

I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry.

I've added this topic to the list.

Thanks!

Quoted 9 lines

Quoted 8 lines

It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them.

This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme.

Quoted 5 lines

Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed.

There are several "maintainance" status there:
S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you should be using that.

Quoted 29 lines

Quoted 7 lines

Quoted 3 lines

We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'.

Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted.

I wrote a small shell script to see what's missing, using the

analyze_build.pl script at media-build devel_scripts dir:

	DIR=$(dirname $0)
	
	$DIR/analyze_build.pl --path drivers/media/ --show_files_per_module

Quoted 1 line

/tmp/all_drivers grep drivers/media/ MAINTAINERS | perl -ne

's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained grep -v

(quoted diff) +0 -2

-f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/
-e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint

I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them.

Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer.

Quoted 7 lines

Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134.

I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose.

These are 'Maintained' by me:

i2c/aptina-pll.ko              = i2c/aptina-pll.c
i2c/mt9p031.ko                 = i2c/mt9p031.c
i2c/mt9t001.ko                 = i2c/mt9t001.c
i2c/mt9v032.ko                 = i2c/mt9v032.c

I can maintain the following driver if needed:

i2c/mt9m032.ko = i2c/mt9m032.c

I could also take over maintenance the following driver, but I don't have access to a hardware platform that uses it:

i2c/mt9v011.ko = i2c/mt9v011.c

These are, as far as I know, co-maintained by Sakari and me :-)

i2c/adp1653.ko = i2c/adp1653.c
i2c/as3645a.ko = i2c/as3645a.c

Hi Martin,

On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote:

Quoted 8 lines

These are 'Maintained' by me:

i2c/aptina-pll.ko              = i2c/aptina-pll.c
i2c/mt9p031.ko                 = i2c/mt9p031.c
i2c/mt9t001.ko                 = i2c/mt9t001.c
i2c/mt9v032.ko                 = i2c/mt9v032.c

Quoted 3 lines

I can maintain the following driver if needed:

i2c/mt9m032.ko = i2c/mt9m032.c

Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ?

Quoted 10 lines

I could also take over maintenance the following driver, but I don't have access to a hardware platform that uses it:

i2c/mt9v011.ko = i2c/mt9v011.c

These are, as far as I know, co-maintained by Sakari and me :-)

i2c/adp1653.ko = i2c/adp1653.c
i2c/as3645a.ko = i2c/as3645a.c

Signature · 3 lines

Regards,

Laurent Pinchart

Quoted 3 lines · Laurent Pinchart

Hi Martin,

On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote:

[ snip ]

Quoted 9 lines

Quoted 9 lines

These are 'Maintained' by me:

i2c/aptina-pll.ko              = i2c/aptina-pll.c
i2c/mt9p031.ko                 = i2c/mt9p031.c
i2c/mt9t001.ko                 = i2c/mt9t001.c
i2c/mt9v032.ko                 = i2c/mt9v032.c

I can maintain the following driver if needed:

Quoted 4 lines

Quoted 1 line

i2c/mt9m032.ko = i2c/mt9m032.c

Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ?

I sadly neigher have time nor hardware to maintain this driver at the moment so i would be more than happy if you can maintain it.

Quoted 10 lines

Quoted 10 lines

I could also take over maintenance the following driver, but I don't have
access to a hardware platform that uses it:

i2c/mt9v011.ko = i2c/mt9v011.c

These are, as far as I know, co-maintained by Sakari and me :-)

i2c/adp1653.ko = i2c/adp1653.c
i2c/as3645a.ko = i2c/as3645a.c

i2c/adp1653.ko = i2c/adp1653.c
i2c/as3645a.ko = i2c/as3645a.c

i2c/smiapp-pll.ko = i2c/smiapp-pll.c
i2c/smiapp/smiapp.ko = i2c/smiapp/smiapp-core.c i2c/smiapp/smiapp-regs.c i2c/smiapp/smiapp-quirk.c i2c/smiapp/smiapp-limits.c

i2c/tcm825x.ko = i2c/tcm825x.c
platform/omap2cam.ko = platform/omap24xxcam.c platform/omap24xxcam-dma.c

Hi Mauro,

On Fri, Nov 02, 2012 at 11:13:10AM -0200, Mauro Carvalho Chehab wrote:
...
These are "Maintained" by me (with Laurent):

Quoted 2 lines

i2c/adp1653.ko = i2c/adp1653.c
i2c/as3645a.ko = i2c/as3645a.c

"Maintained" by me:

Quoted 2 lines

i2c/smiapp-pll.ko = i2c/smiapp-pll.c
i2c/smiapp/smiapp.ko = i2c/smiapp/smiapp-core.c i2c/smiapp/smiapp-regs.c i2c/smiapp/smiapp-quirk.c i2c/smiapp/smiapp-limits.c

"Odd fixes":

Quoted 2 lines

i2c/tcm825x.ko = i2c/tcm825x.c
platform/omap2cam.ko = platform/omap24xxcam.c platform/omap24xxcam-dma.c

Regards,