Hello
hi
mchehab: ping
hmm, maybe he's not around today?
or he's confused by DST again...
I don't know if Mauro has told you all or not, but my dad is extremely ill
i dont think he'll be around very long
I'm very sorry to hear that.
and, unfortunately, havent been able to devote as much time as i should be to work
and definitely not linuxtv
which really upsets me, because i was just getting back into things
but anyway, im sorry
ill become more active again eventually.   circumstances just havent been working out lately :-/
anyway, i took today off work to help my dad with stuff, so i had the time of course to join the meeting
I've been where you are, so just take care of your father. Compared to that linuxtv is very unimportant...
thanks
Hello!
mkrufky: I am sorry to hear that
mkrufky: Sorry to that about your father.
not sure this is relevant but I've been working on IR decoding in bpf and userspace tooling. It's taking a lot of time but it's looking nice, imho. Maybe I'll do an RFC series soon.
thanks guys
gah, missed again :-(
(09:12:13) hverkuil: or he's confused by DST again...
that's teh case
syoung: sounds nice!
I've set the timezone for the meeting reminder as the UTC timezone. Thunderbird translates that automatically to the local timezone taking DST etc into account.
I don't use TB
(well, I do, but only when need to send html emails)
with is usually not the case
I'd expect any calendar application will have something like that.
I should have heard your ping - I'm online since 6am
but there's a problem with my board and HDMI audio - sometimes, it doesn't work
I setup my phone to ring
it was muted :-(
I'm very sorry for that
anything for today's meeting?
Thanks for merging all the pull requests!
from my side, I intend to send the fixes I have merged already later today
anytime
fixes for 4.16?
yes
mchehab: remember I sent a pull request for v4.16
most are related to dvb mmap
I posted a 4.16 cec fix yesterday, haven't made a pull request yet.
https://patchwork.linuxtv.org/patch/47491/
syoung: I saw. didn't handle yet. I'll handle yours (and cec) next week
OK. You still want a pull request?
for fixes, I usually wait for a couple days at -next
hverkuil, yes, please. makes easier to prioritize
Ack
hverkuil, btw, there are some imx patches with the word "pull" on its subject... I'd appreciate if you could prioritize handling them...
as it hits my logic of picking "pull" first
(in the past, it was seeking for "git pull", but, as I received some git pull requests as just "pull", I had to relax it)
I have one request: when you merge a pull request you set the status of the patches to "Superseded". I think "Accepted" is better since the people who posted the patches will get an email saying that it is accepted. "Superseded" is very confusing for them.
Hmm, I don't see any of those patches?
I'll see if I can modify the logic... the thing is that I'll need to verify if the patch merged is identical (except for comments/subject) with the one sent
https://patchwork.linuxtv.org/patch/47372/
So if the patch is identical, do you then set it to accepted? And if not (i.e. the patch merged is slightly different), then to Superseded?
yes, that's the idea
I have already a logic that calculates "patch diff" md5sum
those pwm patches aren't for us, just set them to N/A.
I need to adapt it to do the right thing
At least the patches with 'pull
with 'pull' in the subject
only patch 05/10 has some rc patches
hverkuil, yeah, true. marked the series as N/A
syoung: please review patch 5/10 and ack if you're ok with it
if you ack, I'll ack too :-)
hmm... it seems that there are lots of comments there... so, maybe a v4 will be sent soon
ah, syoung reviewed it already
thanks for that
anything else?
yes those pwm patches are not ready for merging
sailus: what is the progress on the core request api?
hverkuil, just checked: the script that mark patches as superseded already checks the md5sum
hverkuil: -EBUSY
½ an hour.
ok
patches whose diff md5sum is not identical aren't marked
so, I'll just change it to mark them as "Accepted"
mchehab: Thanks. I think that is much more understandable for patch submitters.
yes
agreed
today, I detected a regression at em28xx: webcam support there is broken. It seems related to setting i2c bus speed logic
working on a fix
I'm intending to merge a RFC patch for it making it stop using coherent memory for DMA
that should give some performance gains on non-x86 archs
still, not enough for it to work on Raspberry Pi
What to do with that Elfring guy? I'm inclined to just say 'thanks, but no thanks' and reject any future patches.
most upstream people do that
we spoke about him in person in november, this is Markus
right?
i think we officially decided that we merge patches we REALLY like, only if we really like them, otherwise just ignore him
 SF Markus Elfring <elfring@users.sourceforge.net>
(in his case, i mean)
yep
yeah the guy that makes many of the same exact codingstyle fix in the same single file, broken into 400 patches
I looked at that patch from hime with pinchartl commented...
I didn't see much sense on applying...
on several drivers, it makes worse
I mean:
if (ret < 0) { do_something; return; }
on several cases is better than:
if (ret < 0) goto some_error;
should be driver author's discretion
yep
s/hime with/hom that/
gah
s/hime with/him that/
So I should just reject his patches?
And tell him that we're not interested?
(in his patches0
hverkuil, if you don't agree with his patches, feel free to reject
not sure if explaining to him why you rejected is a good idea
it's not the patches, it's interacting with that idiot that gives me stress.
then, don't interact.
provided that notifications are ok, he'll receive an automatic e-mail saying if the patch was accepted or not
from patchwork
i understand this is the action already taken by other maintainers with him.   no action is probably the best.
yes
OK, will do.
rather, wont do ;-)
Ha!
one thing that concerned me is that Laurent said, at the end of his last e-mail:
"at least until the requested changes are implemented."
even with the requested changes, I don't think we should accept
"[v2] [media] Use common error handling code in 20 functions"
If no warnings are produced, this patch actually makes sense:
Subject: [PATCH v2] [media] Delete unnecessary variable initialisations in  seven functions
That's why I thought I should just mention that we're going to ignore him. Basically, once I've said I'll ignore him, then I actually can ignore him :-)
I don't like the idea of ignoring good patches because of the name of the author
I'd say that, if the patch is doing good, apply, if not, just reject.
On either case, don't hit reply to people we know it will be trolling us
but, at the end of the day, it's your decision
if you feel that it reached a point that applying even good patches cause harms, feel free to ignore everything
(I have the feeling that we didn't reach this point yet, but that's just my impression)
mchehab: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man4/lirc.4 is really out of date.
OK. I'll see what happens.
syoung: currently, man pages generation from kernel-doc is broken
mchehab: should I sent a patch to fix this or just make sure kernel-doc is up-to-date? (There is enough work to be done there)
(not at kernel-doc itself - it is something that happened with the migration to Sphinx)
Feel free to ping "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> and linux-doc ML ( linux-doc@vger.kernel.org)
to see if someone could stepup to fix it
Markus Heiser has some ways to generate man-pages
(still WIP, afaikt)
the main missing part there is generating documentation when tables are present
with is the case of most media documentation
need to go... have another meeting
bye!
bye
hverkuil: I've been lately working on object storage to store stuff related to requests.
It's work-in-progress and not quiet up to review yet.
I could push what I have to a public branch in my tree later today / tomorrow.
If you're interested to take a look.
gnurou might be as well.
sailus: that would be nice. Thanks for the update.