05:15 <chewitt> HackerKkillinghi if sending v2, v3, etc. it's good to include a summary of changes between versions in the cover-letter

05:21 <narmstrong> HackerKkillinghi: and please use git send email because the formatting is wrong: the headers should be in the email headers, no title, no msg id link between patches, lines are wrapped, this makes it impossible to review and apply

06:54 <narmstrong> HackerKkillinghi: ok seems you did in the v3 version thanks :-)

06:55 <narmstrong> HackerKkillinghi: don't forget to add a changelog in the cover letter now!

07:19 <xdarklight> rockosov: thank you! I've seen it but been busy with reviewing the PWM changes and been tracking a regression on one of my boards. I'm hoping that jbrunet can look at your patches

07:19 <xdarklight> rockosov: also note that Friday and Monday were bank holidays in most of Europe so it's possible that Jerome spent time away from his computer (like I also did)

08:32 <jbrunet> rockosov: There is no need to ping after less than a week. There has been comments on this series in the past, especially from the DT maintainers so time is needed. Please be patient. From what I can tell v13 look OK, but it is too late for this cycle. I will have another look at it when rc1 is out.

08:55 <rockosov> xdarklight: jbrunet Thank you for the information. I didn't know anything about European common holidays, so I'm sorry for that. I wish you all the best!

09:00 <rockosov> jbrunet: Regarding the opinions of the DT maintainers, version 12 was marked with RvB by Rob Herring. Unfortunately, I'm not sure if he's okay with the approach where the dt-bindings are split into two patchsets. Regardless, I understand that we need to wait for any feedback from them.

09:02 <jbrunet> rc1 gives them more than enough time to voice concerns, if they have any. Explicit ack from the DT maintainers is not required but any remark should be addressed

09:19 <rockosov> jbrunet: Sorry, I have a question for better understanding. Will the DT binding changes be applied to git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git by you or Neil, or are Rob and Krzysztof responsible for that?

09:30 <narmstrong> rockosov: only the bindings related to amlogic arch/arm64 & drivers/soc, the other subsystems will take the bindings when related

10:24 <f_> HackerKkillinghi: Yeah, use `git send-email`. There's no other convienient way to send patches.

10:24 <f_> And include a summary in the cover-letter! =)

10:24 <HackerKkillinghi> yeah

10:24 <f_> Anyways, how are you doing?

10:39 <HackerKkillinghi> good

10:42 <HackerKkillinghi> check dm f_

10:58 <f_> HackerKkillinghi: Sure.

14:32 <rockosov> narmstrong: jbrunet I cannot find the official schedule for the kernel merge windows/RC preparation. Could you please point me in the right direction?

14:34 <narmstrong> rockosov: https://kernel.org/releases.html

14:34 <narmstrong> "When is the next mainline kernel version going to be released?"

14:36 <rockosov> narmstrong: I thought kernel has realtime calendar with all milestones..

14:37 <narmstrong> rockosov: this is what you want https://kernel.org/release-calendar.ics

14:37 <narmstrong> due to the nature of the project, releases can shift to 1 or 2 weeks so those are only estimations

14:39 <rockosov> narmstrong: In my mind, maintainers should be notified from Linux (or from somebody) about new merge window starts and upstream is opened for branch accepting

14:39 <rockosov> from Linus*

14:40 <narmstrong> rockosov: linus sends release notifications

14:44 <rockosov> narmstrong: So, after the mainline release occurs and the relevant maintainers are notified, the merge window will start automatically

14:54 <narmstrong> rockosov: after a release Linus expects the subsystems maintainers to push their pull request in the 2 weeks window yes, not sure if they are notified, the subsystem maintainers usually prepares the pull request at around rc6 so usually it’s ready when the merge window opens

14:55 <rockosov> narmstrong: now it's clear, thank you

14:58 <rockosov> narmstrong: Why do you prepare several branches in Linux Meson (dt/drivers/fixes)? Is it easier to maintain, or what is the purpose? I'm just curious.

15:11 <xdarklight> rockosov: we have separate branches for the corresponding upstream maintainers. they want separate requests for dt changes and driver changes

15:13 <xdarklight> rockosov: also we can have dt-fixes as well as driver-fixes which are targeting the in-development version (currently: 6.3) while dt and drivers targets the next kernel version (6.4)

15:13 <rockosov> xdarklight: Thank you, I see

15:32 <narmstrong> I suppose Linus asked this separation to Soc maintainers, so I do the same, but yeah it also helps maintaining

17:26 <rockosov> narmstrong: Thanks a lot for explanation