| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | hi all! | [11:55] |
| sailus | Heippa! | [11:55] |
| mchehab | hi all | [12:00] |
| pinchartl | hello | [12:01] |
| mchehab | anything to be discussed this week? | [12:03] |
| hverkuil | Started work on incorporating the changes for the request API. I hope to finish that tomorrow or Monday. | [12:03] |
| sailus | hverkuil: I read them; they seem reasonable enough.
The intended changes, that is. | [12:03] |
| hverkuil | They are minor changes. Updating the documentation with pinchartl's review will likely take the most time. | [12:04] |
| sailus | I'd like to remind still that we need to be very careful about allowing setting controls while requests are queued. | [12:05] |
| hverkuil | That's why there is a warning in the spec. If you want to reword the warning it to make it even stronger then you can propose an alternative text.
I think it is sufficient myself. | [12:05] |
| sailus | Ack.
I've been still reworking the fwnode changes; Jacopo tested them earlier with a parallel bus device. | [12:06] |
| hverkuil | I also spend time on making the vicodec FWHT codec reusable in v4l2-ctl and qvidcap: it's now working. | [12:07] |
| sailus | hverkuil, mchehab: Thanks for reviewing the IPU3 documentation btw. | [12:07] |
| mchehab | wrt request API changes, yeah, your conclusions seem reasonable
I prefer if ou do all changes to be applied after v18 patchset | [12:07] |
| hverkuil | The current video streaming code uses run-length encoding which is obviously really bad for 'real' video (as opposed to test patterns). With the fwht codec you can now stream 'normal' video as well.
mchehab: yes, that's the plan. I really don't want to spin a v19 :-) | [12:08] |
| mchehab | and I really don't want to review a v19 :-D | [12:09] |
| hverkuil | I hope I can finish this request API work soon and continue with the MC properties API. | [12:10] |
| syoung | hi all | [12:12] |
| pinchartl | hverkuil: can't you spin a final v19 by squashing all the small changes you make on top once they all get acked ? that would be a single respin, and would give us a clean history | [12:12] |
| hverkuil | pinchartl: I can, but only if mchehab agrees. I expect to see only a few small correction patches, I don't think it is worth the effort. | [12:13] |
| pinchartl | I suppose it depends how big the effort is :-) | [12:14] |
| hverkuil | pinchartl: I remember that you were working on refactoring (redesigning?) the omap4 DSS code. What is the status of that? | [12:14] |
| pinchartl | if rebasing and squashing creates lots of conflicts it's annoying, otherwise it only takes a few minutes
there are about a hundred patches queued for v4.20 and more to come | [12:14] |
| mchehab | it takes a full day to review a v19 | [12:15] |
| pinchartl | we're (too slowly) reaching the target
mchehab: the idea isn't to review a new version. all changes need to be approved independently, and then squashed before being merged | [12:15] |
| hverkuil | pinchartl: OK, so it is still not in, but it might go into 4.20? | [12:16] |
| pinchartl | you can diff v18 + fixes on top and v19 to make sure nothing got mangled in the process | [12:16] |
| mchehab | if a v19 will be issued, we'll need to review everything again | [12:16] |
| sailus | I'd favour squashing the new changes as well.
mchehab: No need to review the entire set. I'd think seeing the diff is nil compared to v18 + fixes should be enough. | [12:16] |
| pinchartl | hverkuil: I expect part in v4.20 and part in v4.21 | [12:17] |
| sailus | I'd trust the submitter on squashing the fixes to the right patches. | [12:17] |
| mchehab | sailus: no, all patches should be reviewed again, as they will be applied one by one without causing build breakages | [12:18] |
| hverkuil | pinchartl: reason I ask is that CEC for omap5 is one of the few outstanding CEC projects, but it is probably easier to resume work on this once your code is merged. | [12:18] |
| sailus | mchehab: Reviewed or tested? | [12:18] |
| mchehab | both | [12:18] |
| pinchartl | mchehab: if the only concern is build breakages, just run git rebase -x make and have a cup of coffee and tea :-)
hverkuil: have you started working on it ? mchehab: if your concern is functional breakages (as you mentioned testing), then patches *should* be squashed otherwise we end up with functional breekages in bisection | [12:18] |
| sailus | We know the resulting code is the same, so I wouldn't worry overly much about a potential of a fix going to the wrong patch. It'd be in the wrong place otherwise anyway.
So this is between having more or less all the fixes in the right place vs. having them all in the wrong place. | [12:20] |
| hverkuil | pinchartl: I have old code that almost worked (irq issues) | [12:20] |
| pinchartl | so in any case, while I see good reasons to develop incremental fixes on top, I don't see a reason not to then squash them
hverkuil: are you familiar with drm_bridge ? | [12:20] |
| mchehab | well, if I receive a v19, I'll postpone it to when I have a full day available for review | [12:21] |
| hverkuil | pinchartl: let's use a private channel for this, it's not relevant to the media-maint discussion | [12:23] |
| mchehab | non-incremental changes require a lot more time for reviewing than incremental ones | [12:23] |
| pinchartl | mchehab: that's why Hans proposed, and Sakari and I agreed, to develop the changes on top, and only squash them once everything has been finalized and acked | [12:25] |
| hverkuil | I'm not going to make a v19. That takes me too much time for no benefit. No-one is using the request API, so I am not concerned about any 'breakage' during bisect. | [12:25] |
| mchehab | yes, there are no functional breakages for something that is not used yet | [12:26] |
| hverkuil | We're talking about 3 patches (one for documentation, two that change error codes). Not exactly earth shattering. | [12:26] |
| sailus | Squashing three patches takes too much time? | [12:26] |
| pinchartl | the argument goes in both directions :-)
but in any case | [12:27] |
| mchehab | if you point me after the "---" line to what patch they're touching, I may fold when pulling | [12:27] |
| pinchartl | those incremental changes have to be reviewed as such | [12:27] |
| mchehab | (no promises) | [12:27] |
| pinchartl | so let's focus on that first, and get the code ready | [12:27] |
| mchehab | btw, in the specific case of the error code change, I do prefer to have it on a separate patch, anyway
as this will keep the history about why we decided to use that particular approach | [12:28] |
| sailus | hverkuil: Well, feel free to proceed either way, I just wanted to point out the benefits of doing that tiny bit of extra work. | [12:29] |
| pinchartl | mchehab: regardless of whether the patches are squashed, error codes should be explained in the documentation, including the rationale for which code are used when that is important for applications and/or drivers | [12:31] |
| mchehab | sure, but mailing dist (and IRC) discussions are easy to forget after a while... a summary of the discussions don't belong to the documentation, but it can be written on a patch description | [12:33] |
| sailus | You could always put it into the patch description why a particular error code was chosen and another was not.
Anyway, I think we're beginning to attempt splitting hair here. | [12:34] |
| mchehab | yes, but this don't belong into a big non-incremental patch
agreed. Next item for discussions? | [12:35] |
| hverkuil | I can't think of anything. Things should pick up again once 4.19-rc1 is merged. | [12:37] |
| mchehab | yep | [12:38] |
| hverkuil | Once 4.19-rc1 is merged, will you make a topic branch at the same time for reqv18?
That would be nice. | [12:38] |
| mchehab | I'll likely be doing at the same week
but I'll start next week with a trip to the office on Monday... with could place some new items on my TODO list with a high priority of not, my plan is to merge 4.19-rc1, start handling fixes request and create the topic branch next week (on that order) as usual, I should be handling the topic branch after pull request from you with Req-v18 patchset (plus the extra patches to fullfill the latest review requests) | [12:39] |
| hverkuil | ok | [12:44] |
| ........... (idle for 53mn) | ||
| mkrufky | im having a really bad track record. meeting slipped my mind again, i am sorry
but some good news: i booked my edigburgh trip and hotel and conf reg . i will definitely see you all there AND i have a new driver that i am working on :-) | [13:37] |
| .... (idle for 19mn) | ||
| mchehab | mkrufky: your patch-merging track is also not ideal :-) If you have time, please check DVB patches sent by others and send me pull requests...
hverkuil just posted a trivial one | [13:57] |
| .......... (idle for 46mn) | ||
| mkrufky | no problem, ive been away for months
will get on that | [14:43] |
| .............................................................................................. (idle for 7h45mn) | ||
| *** | sailus has quit IRC (Quit: leaving) | [22:28] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |