<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   ***: ChanServ sets mode: +v mchehab
   hverkuil: For our meeting today: I'd like to know opinions on this: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134950.html
   pinchartl: I don't have anything against dropping support for 2.6. 3.0 got released 7 years ago, that seems long enough to me
   <br> 3.10 is 5 years old
   <br> I assume our main target audience is desktop users who want to use the latest media drivers without upgrading the kernel ?
   <br> (possibly running entreprise distros)
   <br> do we have other targets ? 3.4 is still a popular kernel version for android devices I'm afraid
   <br> anything below 3.4 we can probably drop
   <br> I will have to skip the meeting I'm afraid
   hverkuil: I'm not sure we should care about android. It makes no sense to use media_build for that.
   <br> It's really for people running regular distros (ubuntu, debian, suse, redhat), including their enterprise versions.
   pinchartl: I've recommended media_build to a few customers in the past as an easy backport solution when they were stuck with old vendor kernels
   hverkuil: running custom embedded systems?
   pinchartl: yes
   <br> the oldest I have to target these days is v3.12 though
   hverkuil: Good to know. My preference would be to make 3.10 the minimum kernel. It's a pain to keep maintaining old kernels so there have to be good reasons for it, otherwise it's a waste of time.
   pinchartl: I won't oppose to that
   sailus: 3.16 appears to be oldest supported kernel nowadays.
   <br> I'd simply drop anything older than that.
   <br> Just my 0,05 euros. :-)
   mkrufky: there was a time when i used to be able to have patchwork show me all of the DVB patches, only, that needed my review.   did something change?
   <br> is it because none are assigned to me?
   <br> i see two patches from brad, a series from mauro about pads.  i thought there were dvb patches from hans but i dont see them :-/
   hverkuil: hi all!
   mchehab: hi all
   hverkuil: <u>mkrufky</u>: I don't handle dvb, and I can't remember posting dvb patches.
   mchehab: with regards to media_build, I don't have objections of dropping support for 2.6.x
   syoung: Hi
   mchehab: I would try to stick with a Kernel version used by the latest popular LTS regular distros (RHEL, Debian, Suse).
   sailus: Heippa!
   mkrufky: yeah, i thought mauro said you had posted patches.  i was surprised at first to hear that, but maybe it was someone else
   mchehab: as it allows us to get a good test base from users
   <br> <u>mkrufky</u>: I did a good patch cleanup yesteday
   hverkuil: <u>mchehab</u>: and 3.0-3.9? RHEL 7 is on 3.10, which appears the lowest kernel in use.
   mchehab: I applied several stuff for random parts, including DVB
   hverkuil: Suse enterprise is 3.12, debian 8 (7 os obsolete) is on 3.16.
   mchehab: <u>hverkuil</u>: 3.10 seems good enough for me
   mkrufky: ah, ok
   mchehab: of yourse, if you want to (or someone wants to) keep maintaing for older versions, I won't object
   hverkuil: I'll check with Jasmin.
   mchehab: as you sent a RFC to the ML, I would wait for ~1 week for feedback
   hverkuil: I was planning that.
   mchehab: if one wants to keep supporting legacy stuff (other than you/Jasmin), he can be invited to actively contribute
   <br> otherwise, just go for it
   hverkuil: ack
   mchehab: from my side, I don't use media_build for *ages*
   hverkuil: <u>mchehab</u>: question re request_api topic branch: once the cedrus driver is merged there as well, do you plan to merge everything from that branch in our master, or will you do that only when the merge window opens?
   mchehab: that's indeed a good question
   <br> I didn't decided yet
   <br> I guess I'll merge it first at the topic branch
   <br> I'm considering merging it on my linux-next tree (with should be pushed into linux-next too)
   <br> instead of merging directly
   <br> but I'd like to see what conflicts it will rise, if any
   <br> if no conflicts arise, or just trivial ones, I'll likely send a separate pull request upstream
   hverkuil: OK. Good to know.
   mchehab: today (or tomorrow) I intend to merge the pads change together with the tvp5150 patchset, after finishing testing them
   <br> that is the biggest changeset that I skip on yesterday's work
   <br> <u>mkrufky</u>: there is a new dvb patchset there... it still lacks an ack for the DT changes....
   <br> but it would be great if you could review it
   <br> it starts on this patch: https://patchwork.linuxtv.org/patch/51469/
   hverkuil: I don't have anything else.
   mchehab: hverkuil I found some minor things at the Cedrus patch that is doing checkpatch cleanup... I'm commenting it right now
   <br> <u>syoung</u>: there is a pending pull request from you that has some stuff that I commented, and sailus
   hverkuil: ok. BTW, I want them to do a v10 with this cleanup patch and the Kconfig/compile_test fixes merged into the main driver patch. It's causing kbuild noise otherwise.
   mchehab: IMHO, the best is to mark it (and the previous cedrus pull request) as changes requested
   <br> both you and hverkuil can send me another PR after having the pointed issues addressed
   hverkuil: was planning that.
   mchehab: hverkuil, yeah, I see you comment. I agree with you: better to avoid Kbuild noise
   <br> hverkuil, mkrufky, sailus, syoung: as I said to pinchartl yesterday, my scripts are now ready to deal with signed tags. So, when sending me pull requests, please create a signed tag with:
   <br> git tag -s tag_name
   <br> and send me pull requests using such "tag_name" instead of a branch
   hverkuil: You can pick the tag_name yourself, right? Or are there guidelines for it?
   mchehab: same guidelines that applies to a git branch
   <br> I guess the only thing you can't use there are spaces and special chars at the tag_name :-)
   hverkuil: <u>Hmm</u>: error: gpg failed to sign the data
   mchehab: well, you need to have gpg setup on the machine you're generating it
   <br> it has to have access to your private key on his keychain
   hverkuil: Does it use the email address from .gitconfig to sign it?
   mchehab: I guess that's the default
   <br> there are probably some ways to use a different key
   sailus: <u>mchehab</u>: \o/
   mchehab: https://help.github.com/articles/telling-git-about-your-signing-key/
   hverkuil: my keychain is for hverkuil@xs4all.nl, while email is set to hans.verkuil@cisco.com. I'll dig a bit deeper.
   mchehab: hmm. this is github
   <br> I'm pretty sure there's an option on git to point to the key ID you want
   sailus: I'll probably need to do some tweaking to get my keys arranged the right way...
   mchehab: git config --global user.signingkey 3AA5C34371567BD2
   <br> (step 4 of that tutorial I pointed)
   syoung: <u>mchehab</u>: would it make sense to merge my pull request without the two n900 patches? Or should I resubmit another pull request without them?
   mchehab: if you want, I can skip the two n900 patches if the other ones aren't depentent on it
   <br> usually, when I have issues with the first patch on a series, I generally just skip it, assuming that the other patches there might depend on it
   syoung: they are not dependent. It's the first two patches
   mchehab: if that's not the case, I can skip just them and apply the rest
   <br> Ok! I'll handle the remaining ones then
   syoung: thanks!
   mchehab: anything else for today's meeting?
   hverkuil: Not from me. And I just managed to make a signed tag :-)
   mchehab: good!
   <br> yeah, it is not hard to do that
   hverkuil: I was missing 'export GPG_TTY=$(tty)' in my .bashrc
   mchehab: ah, for the gpgagent... I remember I had to use some special settings for it to work a long time ago (with an old Fedora distro)