Hi Martin,
On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote:
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:
Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil escreveu:
On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote:
Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil escreveu:
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.
[snip]
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!
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.
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.
[snip]
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.
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
Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ?
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