[alsa-devel] More HDA NID / control / proc related changes

[Takashi Iwai]

At Tue, 15 Dec 2009 09:42:04 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Mon, 14 Dec 2009, Takashi Iwai wrote:
> 
> > At Mon, 14 Dec 2009 16:45:18 +0100 (CET),
> > Jaroslav Kysela wrote:
> >>
> >> Anyway, I created for-next branch in my repository. Could you import changes
> >> without explicitly asking if you do not have any comments? I'll merge
> >> patches from Clemens there as well.
> >
> > Could you rebase it rather on the latest Linus tree instead?
> > Or, rebase it on topic/hda branch I opened now for 2.6.34
> > development.
> >
> > My master branch is for the development tip, and its merge history
> > is pretty messy.  Ditto for for-next branch.  It contains lots of
> > unneeded merge commits.  The merge history gets straightened when
> > backed to for-linus branch.
> >
> > If your changes are only for HD-audio, then you can branch from either
> > fix/hda or topic/hda branch in my tree.  The former is for the current
> > kernel and the latter for the next kernel.
> > For ASoC, fix/asoc and topic/asoc, and for others, fix/misc and
> > topic/misc branches are available for (relatively) straight history.
> >
> > I cherry-pick'ed the last commit of Clemens to topic/misc.
> > So I'd need only your topic/hda-nid branch for merge.
> 
> Ok, I would propose a bit different approach. I created two new branches
> in my tree:
> 
> fixes - for current kernel
> devel - for next kernel
> 
> To avoid too many merges, I would like that you pull from these branches
> only when you compose the changeset for Linus (fixes) or for your next 
> kernel (master branch - pull from fixes+devel). In case of problems or 
> comments, I will fix them with new patch (so, in these trees, my patches 
> will have stable SHA keys).
> 
> Do you think that it will work for you?

Yep, that'll be fine.

BTW, I found Steve's ac97 patch in your fix branch.  I haven't applied
it just because 5 seconds don't look like a "right" fix.  Though, it
will unlikely regress on other hardwares, it's OK to just take it as a
"workaround"...  I'll merge that tree, too.


thanks,

Takashi