On Mon, 04 Jun 2018 15:27:18 +0200, Pierre-Louis Bossart wrote:
On 6/2/18 4:00 AM, Takashi Iwai wrote:
... and these patches are touching both ASoC and HD-audio legacy, we'd need the coordinated patch application. That is, we'd need a topic branch that will be merged to both Mark and my trees. We can branch it off after 4.18-rc1 release, for example, as a clean start point.
... And I am not sure I understand the topic branch merged in both directions. If we want to perform a non-regression with the first parts (without ASoC additions) then we may need to create a partial topic branch, then add the rest later?
The topic branch is needed so that it can be merged in my tree and Mark's tree directly and cleanly. It has nothing to do with 'no regression' rule, but rather only about the git merge mechanism.
Usually a topic branch is created from a clean stub point, e.g. Linus 4.18-rc1 release. Then I'd merge your patches starting at this point, so that these can be merged via git-merge to both my tree and Mark's tree at the same time. At later point, I'll merge whole Mark's tree for 4.19 merge window. And the merge will work cleanly since these common changes have been already merged in my tree.
The split of patches are helpful to ease reviews in general. For this kind of big mixture changes, some staged merges are preferred. That is, at first merge individual fixes, and merge preliminary / cleanup patches that don't break any functionality. These can be merged and tested quickly, per nature.
Then it follows the rest, the main change; this will need more careful reviews and tests, and it'd be often requested to rewrite multiple times. When the preliminary patches have been already merged, you don't have to resend the whole series again, and this will make the mail thread a lot easer to read through.
thanks,
Takashi