| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | mchehab: just a heads up: unless something unexpected happens I'll make a new PR tomorrow for 5.3 with the first three patches from the "cec: improve notifier support, add connector info" series I posted yesterday.
This makes life much easier for the 5.4 cycle since all further changes in drm and media can be done independently without requiring cross-subsystem patches. | [06:53] |
| ..... (idle for 23mn) | ||
| RFC: can we please kill off drivers/staging/media/soc_camera for 5.4?
Candidates for outreachy or linux kernel mentee projects keep trying to 'clean them up', and I think keeping BROKEN drivers around is just a really bad idea. | [07:18] | |
| .................................... (idle for 2h56mn) | ||
| mchehab | hverkuil: I don't see any issue on a mentee that want to work on soc_camera... they just need to convert the drivers and test them after the changes
it is up to the mentor to put them into the right direction (or to convince them to select a different target) removing stuff from the kernel just because a mentor can't convince the mentee to do what should be done sounds stupid :-p with regards to PR, as I said before, I'll be OOT next week, being without Internet access - so I'll probably stop merging patches a little earlier this time so, the earliest you send me a PR, the more likely it will be merged for 5.3... yet, as I said before, it is not a good idea to send big patches like driver additions the very last week before the merge window (I mean: "before the merge window freeze" - with happens one week before the actual merge window) | [10:16] |
| ..... (idle for 23mn) | ||
| hverkuil | mchehab: I meant soc_camera style patches like this: https://patchwork.linuxtv.org/patch/57074/
Nobody will be converting those drivers as an internship project since that requires specialized hardware. Generally not an option for interns. I plan on posting the PR this evening. | [10:45] |
| mchehab | hverkuil: well, if one really wants to do it, he could buy the hardware and do the patch - otherwise the mentor should tell them to say out of that
btw, the TODO tells what it is expected there: $ more drivers/staging/media/soc_camera/TODO The SoC camera framework is obsolete and scheduled for removal in the near future. Developers are encouraged to convert the drivers to use the regular V4L2 API if these drivers are still needed (and if someone has the hardware). at very least, I would expect that any mentor would tell their mentees to read TODO when touching at drivers/staging | [10:49] |
| hverkuil | It seems we have different views on this. I hate having dead code in the kernel. What's the point of git if you still keep old dead code around?
Anyway, not important enough to make a big deal of it. I'll just keep rejecting patches touching on soc_camera. | [10:51] |
| mchehab | I'm ok to make the TODO even clearer, explicitly stating that we'll *only* accept patches converting the drivers
hverkuil: yeah, our views are somewhat different with regards to staging for me, staging is a sort of trash can, where we place bad code ok, we should not keep stuff there for too much time | [10:52] |
| hverkuil | bad code, yes, but broken code is where I draw the line. | [10:56] |
| mchehab | as, from time to time, we need to recycle the trash can
I have a hysteresis criteria with regards to broken code I won't accept adding a broken code to staging... but I won't use broken code as my removal criteria.. instead, I use other criteria for removal : - don't build anymore - prevents of makes the introduction of a new feature too complex - it is at staging for a long time so, yeah, the third criteria will eventually reach the soc_camera drivers but there are some stuff under drivers/staging/media/ that are older than soc_camera I mean soc_camera -> staging patchset that's said, what is a "long time" for staging i something that we never defined omap24xx and omap4iss, for example, are there for a very long time (IMHO), without any patches addressing the issues that made them to go to staging I'm not seeing any efforts to move imx out of staging ... I propose adding this as a theme for our next Media Summit: criteria to remove drivers from staging syoung: just sent a dvb patch today. Care to review and ack or merge though your tree? (it is a no-brainer - yet, I'd like to have at least 2 SoBs for patches that do functional changes) | [10:56] |
| hverkuil | mchehab: can you post that topic to media-submaintainers? Let's collect all such ideas there.
Any progress finding a location? | [11:06] |
| mchehab | by SOB here - I actually mean: sob, review, ack or test)
hverkuil: no... didn't have much time to chase for a location myself will re-ping KS/Plumbers comittee Just sent an e-mail to LF... maybe they could help us to rent a location | [11:06] |
| pinchartl | hverkuil: for what it matters, I agree with you, I'm fine removing that code | [11:12] |
| mchehab | The soc-camera driver went to staging on Thu Feb 7 08:43:47 2019 -0500
if we're removing it, we should also remove the other drivers that went to staging before Feb, 2019 omap24xx last patch: commit db85a0403be4a59cf536a25622fe110feefba8d3 Date: Fri Nov 14 10:19:47 2014 +0100 | [11:14] |
| hverkuil | but the others aren't dead code. That's the key difference for me. | [11:17] |
| mchehab | for me, a driver at staging that it is there for 4 years without anyone touching it is dead | [11:18] |
| hverkuil | that said, I think bcm2048 and omap4iss are candidates for removal unless someone actually steps up and finishes them. | [11:18] |
| mchehab | my proposal here is to discuss those things at the summit
check when the last time people did a non-cleanup contribution to the stuff under staging if it is more than, let's say, 12 months, I would "tag" it to be subject to removal we should make a public announce about what will be removed and when... if nobody steps out to fix, we just send to /dev/null it sounds that the last functional changes at omap4iss that were not due to a kAPI change were back on 2015 | [11:19] |
| hmm... omap24xx were already removed - sometimes git keeps the old dirs - even without any files on them
hverkuil: yeah, I agree that bcm2048 and omap4iss are good candidates for removal | [11:29] | |
| hverkuil | ditto davinci_vpfe | [11:31] |
| mchehab | yep
lots of cleanup, but I'm already at 2016 logs - no changes directly related to its code so far I guess this is the last patch specific to DaVinci: commit 171fe6d1270d535eae798e4b5acc9f5d25e6e17e [media] media: davinci_vpfe: set minimum required buffers to three Actually, this one commit 4f26aa17860dadbfb861d8701224c52275ca8593 Date: Mon May 25 12:34:29 2015 -0300 2015 | [11:31] |
| hverkuil: just sent a patch proposing a date for those legacy code to RIP
still, IMO we should discuss at the media summit about a criteria for getting stuff out of staging | [11:48] | |
| sent a proposal for the next media summit for such discussions too | [12:00] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |