I'll be a bit late from the meeting today. Probably between 5 and 10 minutes.
hi all
EHLO
hello :)
hi
hi
it seems hverkuil is having some connection troubles
anyway, let's start today's meeting. he may look at the logs later on
as said last week, the media merge window is closed. I wrote a few patches to reduce the amount of warnings with sparse/smatch, but I'll apply them after 4.13-rc1
I'll be out for vacations on the next two weeks, with will likely be the upstream merge window...
so, my plan is to send a pull request early at 4.13 merge window, and only read e-mails related to merge window issues
feel free to send me e-mails in private if something bad happens
I won't otherwise be reading random e-mails during such weeks
right now, that's the summary of patchwork:
Number of pending patches per reviewer:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> : 164
LinuxTV community : 90
Hans Verkuil <hansverk@cisco.com> : 67
Sakari Ailus <sakari.ailus@iki.fi> : 34
kamil@wypas.org : 27
sean@mess.org : 19
Silvester Nawrocki <sylvester.nawrocki@gmail.com> : 19
m.chehab@samsung.com : 17
https://pastebin.com/asiAEnpD
there are a high number of patches there that are more than 6 months old
I think we should try to merge the ones that have more than 6 months old, still apply and won't cause regressions on other drivers and don't have uAPI changes at the beginning of 4.14 development cycle (e. g. after 4.13-rc1 gets released)
comments?
mchehab: Mine are mostly patches I need to discuss with Pavel.
They're mostly unapplicable.
mchehab: I plan to go through all my pending patches as soon as we reach a conclusion regarding the maintenance process discussion
(sorry, the above numbers are old... I forgot to update my local cache... the actual patches are at: https://pastebin.com/a2cpSYwC)
pinchartl: I haven't seen any recent comments about the maintenance process discussion at the media-maint ML
OK, my vdsl dropped out right as this meeting was about to start.
using my mobile as a hotspot for now.
mchehab: Hans said he would post an update today
hverkuil: https://linuxtv.org/irc/irclogger_log/media-maint?date=2017-06-29,Thu
A phone call...
regarding the media process proposal: I plan to post an updated version tomorrow.
hverkuil: sorry. today, tomorrow, I always confuse them :-)
I want to finish a big chunk of CEC work today before switching context.
hverkuil: no worries. I know the feeling
sailus: with regards to those patches that need discuss, we created a new status (TODO)
I guess the best would be to move them to the TODO status
I need to modify my script to catch such status - and to update the automatic message about status update do describe it
mchehab: I'm still working on the lirc_zilog driver, and I'd like to hold back the 10 lirc scancode uapi patches back until that is done.
I'm not sure I like the TODO status. it sounds like a duplicate of the new status, where patches will stay in limbo forever as they do in the new status now
syoung: OK
mchehab: I have started reviewing the other patches but that's not done yet. I've also started on a bitbang gpio and pwm gpio ir tx so we can supported rpi IR hardware better
syoung: that sounds interesting. I have a few RPi hardware here (but none with IR RX or TX hw). If you send me in priv an e-mail with hw details, I may be able to get some extra hardware to test such features when done
Back!
at least patches with "new" status not deletated to anyone, I periodically review them, once or twice per Kernel release
mchehab: I have a few patches there only, and I can check these with Pavel in the near future.
s/deletated/delegated/
If they're moved elsewhere, the bar for handling them is higher, at least for me. :-)
Perhaps for some of them that should be the right choice actually.
my guts tell that, if nobody is actively doing something with regards to those "forgotten new" patches, the best is usually to apply...
except if are there something serious on them
(like the risk of core regressions)
mchehab: a large number of patches delegated to me should *not* be applied
but, if they require changes to avoid regressions, then it is best to use a new status
I'm thinking about patches from Markus Elfring for instance
(that's the goal of TODO)
pinchartl: I'm OK if you just mark all of them as Rejected
mchehab: I'll go through them, as soon as we come to a conclusion
(still, I applied myself a (very small) amount of Markus Elfring patches - as they were doing the right thing)
there are number of quite obvious patches for staging, which could be rejected or applied: https://patchwork.linuxtv.org/project/linux-media/list/?q=staging
I don't have that many old non-TODO patches. I plan on going through them fairly soon.
rather than TODO, how about BLOCKED or IMPEDED?
the way I handle such patches is: if are there anything wrong, I simply reject
I did once too and they introduced a bad regression
otherwise, if it is 100% correct, I apply
if there's a maintainer for a driver, and a patch marked as new for a long time, in most cases it means that the patch is incorrect
syoung: the idea of TODO is for things that are needed, but the patch is not quite ready
and that's how they should be treated by default
if the patch isn't ready then a new version is requested, that's how it should be marked. not as todo
good point
https://patchwork.linuxtv.org/project/linux-media/list/?state=12
TODO patches ^
IMHO, TODO makes sense as a sort of "reminder list" of things that are important, but we don't have time to do it ATM
in my case, I would mark this as TODO: https://patchwork.linuxtv.org/patch/40628/
(on this specific example, something has to be done with regards to USB alignment in order to fix UVC driver on RPi3 - but there's no consensus yet about the solution)
mchehab: This looks like a landfill of patches.
Recycling is what's done to waste nowadays.
mchehab: you're trying to turn patchwork into a todo list manager, and I'm not sure that's a good idea
Perhaps these could be re-used, and if they're not completely right, use them as parts for new patches? :-)
pinchartl: the actual proposal came from hverkuil
we all agreed last meeting
(that doesn't mean we can't/shouldn't revert such decision)
mchehab: I guess we should still try to keep the numbers small.
mchehab: I don't care much personally, I just think it's not a very good idea
yes, agreed
sailus: ^
I'll just drop mine, why it wasn't applied was that it didn't really help solving the problem it was written for.
pinchartl: I didn't mark any of my stuff as TODO
mchehab: Fine with that.
I guess we could keep it for a while, and see how it behaves
if it ends to be a bad idea, we can re-tag them as New and remove TODO status
Sounds good.
btw, the difference between "Changes Requested" and "TODO" is that Changes Requested disappears from the patch queue
I use TODO for patches that should not be applied, but that I want to keep archived for later.
while TODO stays
But perhaps I should manage that differently by making a mail folder where I can drop them into.
as patchwork puts it the same level as "new" and "under review"
the advantage of placing it at patchwork is that such list is visible to the world
Hmm, I get the feeling someone cut through the DSL line :-(
:-(
sorry about that
I'll read the log later
back to TODO, let's keep it for now, and see what happens. OK?
sorry, I've been very distracted by this DSL issue.
I have nothing to report anyway. EVerything I wanted to get merged is in, so I'm good.
Please check if this description for TODO and Changes requested are OK:
Changes requested: when someone requests changes at the patch;
TODO: when a patch is not OK, and was requested to be changed, but it
is for some feature that it is needed to be tracked.
(those are for patchwork automatic answering e-mails)
That doesn't really cover it.
ok. Have an alternate text?
I think it is much better if I copy these patches into a mailbox folder, then change the status from TODO to RFC. Looking at the list of patches I marked TODO
I see that they are really of the RFC type.
But if I mark them as RFC they disappear from the todo list.
TODO: A variant of RFC. It keeps the patch visible at patchwork main
screen, allowing to better track them.
I have my own todo list that I maintain, if that was public (somehow) then people could contribute to those issues :)
that's the current content of the patchwork's email: https://pastebin.com/w57gQUz8
syoung: yeah, that's one of the good things of a public TODO list
(yet, as pinchartl pointed, if the best is to keep it at patchwork or outside is a question yet to be answered)
nothing prevents to have both
a TODO list at patchwork for things that were submitted as patches, and a TODO list at Wiki for the rest
(and/or maybe somewhere at Documentation/media for things that we want to be more publicly visible)
hverkuil: is that TODO description OK?
any other comments for other descriptions at https://pastebin.com/w57gQUz8?
mchehab: I would be very happy with a wiki page for rc-core todo. Shall I go ahead and create one on linuxtv.org/wiki?
yes, sure
mchehab: looks ok.
this description of the TODO state makes much more sense.
About not applicable --- does that mean that a patch is not meant to be applied through the media tree?
please add it in a way that we can further extend to other parts of the subsystem
yes
for example, my own pull requests to Linus are marked as not_applicable
patches for DRM c/c to our ML are also marked as not_applicable
Then s/applicable/applied/. Applicable means that it is possible to apply.
because they will (or will not) go through some other tree
Not Applicable: for patches that aren't meant to be applyed via
the media-tree.git.
Not Applicable: for patches that aren't meant to be applied via
the media-tree.git.
mchehab: Ack.
ok, changed
mchehab: looks good
ok. anything else?
I read through it cursively and the rest looks good to me.
ok, if there's nothing else for todays meeting, let's finish it...
as a reminder, I won't be here on the next two weeks
I'd like to say something still.
Not important right now but in the near future perhaps.
(actually, I might - depending on what I'll be doing on the next two Thrusday mornings)
mchehab: "Changes requested: when someone requests changes at the patch;" I think that "at" is wrong.
sailus: go ahead
mchehab: maybe "Changes requested: when someone requests changes of the patch;"
I'll have fwnode improvements for the linux-pm tree and there are a few V4L2 related patches included, mostly V4L2 fwnode framework.
syoung: changed, thanks!
I'd like to get them in through the linux-pm, as long as the changes remain quite limited.
I'll post more in the near future.
Just as a heads-up.
OK
if this goes after the merge window, it should trivial to do that
Yes, it'll be post merge window.
ok
just be sure to send to linux-pm c/c our ML just for us to ack (if needed) and to be aware of such changes
mchehab: Certainly.
Acks will be required for going through linux-pm tree, that's for granted.
we may need a stable branch at linux-pm, if some of the changes over there would cause merge conflicts with other patches coming via our tree
From linux-media, that is.
Let's see. I expect the changes to stay rather local.
But more on those later.
ok
I guess we're done then?
from my side, yes
Unless someone else wants to bring something up. :-)
I'll have another meeting in 10 mins
mchehab: enjoy your vacation!
thanks!
I think these meetings really help facilitate the work.
agreed
mchehab: Have a relaxing holiday!
thx
Btw. I'll be away for the next week, too.
I'll check my e-mail occasionally though, I won't be on a top of a mountain or anything. ;-)
Thanks for the meeting!
ok, thank you all
take care
thanks, have a good holidays!
thx
thanks everyone
OK, I'm reconnected to the world! :-)
That feels much better...