[For Peter and Ingo, we are discussing commit 621a0d5207c18012cb39932f2d9830a11a6cb03d ("hrtimer: clean up unused callback modes") that went into Linus' tree yesterday but broke the sound tree in linux-next which used one of the removed defines.] Hi Takshi, On Fri, 14 Nov 2008 08:07:44 +0100 Takashi Iwai wrote: > > To defense myself: the reason of the rebase is irrelevant with this > build error. It's just a sad coincident. There is no need to defend yourself, as you say a sad coincidence. I am sorry if dropping the sound tree has made you feel attacked, it is just the new way I am doing things - I cannot fix every problem, so I will not try in most cases. The sound tree will be restored as soon as this is fixed up. > I had to rebase the sound tree because I need to drop one topic branch > which cause another build error. Of course, I could revert each 15 commit > of that topic branch, but it's also annoying. Thus I decided to rebase > (just re-merging each topic branch again from scratch). And that is perfectly fine. As you said the rebase had nothing to do with this new build error. > I'm wondering why this happens, though. Such a clean-up patch should > has been tested enough long on linux-next before pushed into Linus > tree. And, I see no reason to push a clean-up patch at this late rc > stage... A lot of stuff goes into Linus' tree without entering linux-next at all. But, as you say, this clean up patch, and, coming through the tip trees, I would have expected to be in linux-next for at least a day ... Things like this happen all the time ... -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/