[alsa-devel] [PATCH v3 00/13] Enable HDA Codec support on Intel Platforms

[Takashi Iwai]

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