Message ID | 20210204052043.388621-1-bjorn.andersson@linaro.org (mailing list archive) |
---|---|
State | Mainlined, archived |
Commit | 7790114893c537176ebab62d002a261b5f01f7a9 |
Headers | show |
Series | [GIT,PULL] Qualcomm ARM64 DT updates for 5.12 | expand |
From: Arnd Bergmann <arnd@arndb.de> On Wed, 3 Feb 2021 23:20:43 -0600, Bjorn Andersson wrote: > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.12 > > [...] Merged into arm/dt, thanks! I noticed that this came fairly late in the cycle and has a fairly large amount of changes in it. It would be nice if you could try to send some of the DT contents a little earlier in the future to avoid risking them to miss out. It could also help to split up the largest branches to make them a little smaller, e.g. by having one branch just for new SoC and/or new board support, and another branch for changes to existing machines. merge commit: 8a2b1ec1708566e032f22a95635ac2d105103b42 Arnd
On Tue 09 Feb 17:06 CST 2021, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > On Wed, 3 Feb 2021 23:20:43 -0600, Bjorn Andersson wrote: > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > > > are available in the Git repository at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.12 > > > > [...] > > Merged into arm/dt, thanks! > > I noticed that this came fairly late in the cycle and has a fairly > large amount of changes in it. It would be nice if you could try > to send some of the DT contents a little earlier in the future to > avoid risking them to miss out. > Yeah, sorry about it showing up late. I'm trying to balance it because I do feel frustration from the contributors that the Qualcomm branches are "locked down" for 4-5 weeks per cycle. > It could also help to split up the largest branches to make them a > little smaller, e.g. by having one branch just for new SoC and/or > new board support, and another branch for changes to existing machines. > It's fairly common that things such as PMICs are reused between new and old platforms, so I fear that such a split will cause unnecessary conflicts between my trees. Perhaps I should just send multiple pull requests throughout the cycle? Regards, Bjorn
On Wed, Feb 10, 2021 at 12:26 AM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Tue 09 Feb 17:06 CST 2021, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > On Wed, 3 Feb 2021 23:20:43 -0600, Bjorn Andersson wrote: > > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > > > > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > > > > > are available in the Git repository at: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.12 > > > > > > [...] > > > > Merged into arm/dt, thanks! > > > > I noticed that this came fairly late in the cycle and has a fairly > > large amount of changes in it. It would be nice if you could try > > to send some of the DT contents a little earlier in the future to > > avoid risking them to miss out. > > > > Yeah, sorry about it showing up late. > > I'm trying to balance it because I do feel frustration from the > contributors that the Qualcomm branches are "locked down" for 4-5 weeks > per cycle. > > > It could also help to split up the largest branches to make them a > > little smaller, e.g. by having one branch just for new SoC and/or > > new board support, and another branch for changes to existing machines. > > > > It's fairly common that things such as PMICs are reused between new and > old platforms, so I fear that such a split will cause unnecessary > conflicts between my trees. > > Perhaps I should just send multiple pull requests throughout the cycle? That's what most others do that have a lot of contents, that definitely works for me. Just use whichever way works best for your workflow. If you have the usual ~200 changesets for a merge window, it would be great to have the majority of those some time between rc3 and rc5, with anything that you are not comfortable with committing early in one of the later pull requests. I don't mind getting a last-minute fixup or revert of an earlier change when you have sent something earlier that looked good but it turned out to be incorrect during testing. Arnd