Hi Mauro, 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. > > > > > > > > Thank you for taking care of it. > > > > > > > > > - 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. > > > > > > 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. > > > > (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". > > > > > > 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 <mchehab@xxxxxxxxxxxxx> (maintainer:MEDIA INPUT > > > > INFRA...,commit_signer:7/7=100%) Hans Verkuil > > > > <hans.verkuil@xxxxxxxxx> (commit_signer:4/7=57%) > > > > Anatolij Gustschin <agust@xxxxxxx> (commit_signer:1/7=14%) > > > > Wei Yongjun <yongjun_wei@xxxxxxxxxxxxxxxxx> (commit_signer:1/7=14%) > > > > Hans de Goede <hdegoede@xxxxxxxxxx> (commit_signer:1/7=14%) > > > > linux-media@xxxxxxxxxxxxxxx (open list:MEDIA INPUT INFRA...) > > > > linux-kernel@xxxxxxxxxxxxxxx (open list) > > > > > > > > According with this driver's copyrights: > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights > > > > Reserved. > > > > * > > > > * Freescale VIU video driver > > > > * > > > > * Authors: Hongjun Chen <hong-jun.chen@xxxxxxxxxxxxx> > > > > * Porting to 2.6.35 by DENX Software Engineering, > > > > * Anatolij Gustschin <agust@xxxxxxx> > > > > > > > > The driver author (Hongjun Chen <hong-jun.chen@xxxxxxxxxxxxx>) 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. > > > > > > 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 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 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
