06:34:10 * ** patersonc has joined #cip
07:12:41 * ** rajm has joined #cip
07:53:10 * ** toscalix has joined #cip
07:58:53 <rajm> BBB healthcheck runs with email to the list
08:14:31 <rajm> the renesas HC however.... :-(
08:23:25 <rajm> though again replacing our initramfs with the yocto core-image-minimal-iwg20m gets the HC to run
08:31:42 * ** moxavictor has joined #cip
08:38:37 <szlin> Here is the proposed agenda for the meeting:
08:38:46 <szlin> Kernel patch review status
08:53:41 * ** vidda_ has joined #cip
09:00:09 <rajm> but a second attempt at running test (again using core-image-minimal-iwg20m) with lava-tool fails
09:00:40 <szlin> time for CIP-dev IRC weekly meeting
09:00:59 <moxavictor> hi everybody
09:01:05 <szlin> #startmeeting
09:01:24 <patersonc> hi
09:01:33 <szlin> #topic Roll Call
09:01:36 <toscalix> hi
09:01:39 <vidda_> hi
09:01:40 <weshuang> hi
09:01:42 <rajm> hi
09:01:43 * szlin please say hi if you're here
09:02:12 <patersonc> hi
09:02:15 <moxavictor> who know to review kernel patch faster ?
09:02:32 <szlin> #topic 1. Kernel patch review status
09:03:05 <szlin> I have sent the status of review email in kernel 4.4.129
09:03:34 <szlin> We did not see any problematic patches
09:03:55 <toscalix> szlin: do you mean you guys reviewed the patches sent to the mailing list?
09:04:02 <szlin> yes
09:04:15 <toscalix> directly in the 4.4-stable mailing list?
09:04:28 <szlin> nope, in cip-dev
09:04:47 <szlin> as Ben said before.
09:05:42 <szlin> Email content
09:05:42 <szlin> ====
09:05:45 <szlin> The following items in 4.4.129 are reviewed and mark as LGTM:
09:05:52 <szlin> 6f051f8986a8 writeback: safer lock nesting 4533f7e1785f watchdog: f71808e_wdt: Fix WD_EN register read
09:05:55 <szlin> b7b4411c8990 clk: mvebu: armada-38x: add support for missing clocks
09:05:58 <szlin> 60f6c860c258 HID: core: Fix size as type u32 0ab6b8c91ecf usb: dwc3: pci: Properly cleanup resource
09:05:59 <toscalix> ah, so you sent the summary
09:06:01 <szlin> 318a306c53d1 ARM: dts: at91: sama5d4: fix pinctrl compatible string 31118e88019f ARM: dts: at91: at91sam9g25: fix mux-mask pinctrl property
09:06:02 <toscalix> ok
09:06:04 <szlin> e23007895028 usb: musb: gadget: misplaced out of bounds check 085c9c4b9e7e cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN
09:06:06 <toscalix> got you
09:06:07 <szlin> SZ
09:06:10 <szlin> ====
09:06:49 * ** HarryYJ_Jhou has joined #cip
09:07:31 <szlin> After this review, victor has a question that "how to review kernel patch in a efficient way"
09:08:15 <toscalix> moxavictor: since bwh is not here today, I am afraid you will have to send a mail to cip-dev asking the question
09:08:32 <moxavictor> got it
09:08:59 * ** Tzongyen_Lin has joined #cip
09:09:12 <szlin> we will continue to review the patch - 4.4.130 and send out the review summary to cip-dev.
09:09:50 <patersonc> szlin: Am I wrong in thinking v4.4.131 has already been released?
09:10:14 <szlin> yes, 4.4.131 was released 16 hours ago
09:10:29 <szlin> The release cycle is so quick
09:10:45 <toscalix> you cannot pretend to beat the big guys, this is about learning
09:10:46 <szlin> therefore, victor has that question - how to review kernel patch in a efficient way
09:11:16 <toscalix> I would not focus at this point to be up to date
09:11:43 <toscalix> pick up some of the latest patches, and if it takes longer for you, fine
09:11:56 <szlin> that's my thought, stay tuned.
09:12:02 <toscalix> if you detect a bug, you check if somebody else did already, and that's it
09:13:03 <toscalix> the process is based on having many users testing the patches, not neccesarily the reviewrs themselves
09:13:16 <szlin> review the patch step by step and no hurry
09:14:00 <toscalix> bugs landing in 4.4-131 were discovered in 4.4.50, for instance
09:14:02 <moxavictor> so, we don't need to review every commit ?
09:14:36 <toscalix> I would focus first in those which areas you understand and have more control over. You would be more likely to discover issues there
09:14:37 <patersonc> moxavictor: Perhaps just review patches relevant to your interests/experience for now?
09:15:02 <moxavictor> OK.
09:15:17 <toscalix> and expand your knowledge little by little
09:15:33 <toscalix> this is about adding value, not about review coverage
09:16:01 <moxavictor> we can learn what to review patch ?
09:16:34 <toscalix> reviewers and maintainers read a lot of docu
09:16:41 <toscalix> to do the reviews
09:16:41 <moxavictor> coding skill ? kernel software architecture ?
09:17:49 <toscalix> I see reviewers as experts in the kernel development and maintenance process, with a good general overview of how the kernel is structure and works and then they have one or two areas where they excel
09:18:04 <toscalix> technical areas
09:18:17 <toscalix> in the rest, they most likely have to read documentation
09:18:26 <toscalix> they usually know more about problematic areas
09:18:35 <toscalix> that has required a lot of review lately
09:18:59 <moxavictor> where we can read it ?
09:19:40 <toscalix> I am talking from my experience managing kernel hackers
09:20:28 <szlin> for development process: https://www.kernel.org/doc/Documentation/process/
09:20:40 <toscalix> I am not aware of a document about these things. Include this in your question to Ben. I asked him some time ago but maybe there is a new blog post out there useful about these topics
09:21:55 <moxavictor> good, could I get the blog home page ?
09:22:12 <toscalix> ... but maybe...
09:22:37 <toscalix> I mean, I haven't seen anything new/good about this. I would ask Ben if there is something recent
09:22:50 <toscalix> there was not last time I asked him, a few months back
09:23:27 <moxavictor> OK
09:23:52 <moxavictor> thanks
09:25:09 <szlin> any other questions for patch review?
09:26:28 <szlin> #topic Miscellaneous
09:26:35 <szlin> anything to discuss?
09:28:16 <moxavictor> no question
09:28:23 <toscalix> _o_
09:28:26 <szlin> #endmeeting