From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: linux-next: sound tree build failure Date: Fri, 14 Nov 2008 08:41:31 +0100 Message-ID: References: <20081114145630.31f312ce.sfr@canb.auug.org.au> <20081114175856.2ab38113.sfr@canb.auug.org.au> <20081114182718.e93352c3.sfr@canb.auug.org.au> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from ns2.suse.de ([195.135.220.15]:43196 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750727AbYKNHlc (ORCPT ); Fri, 14 Nov 2008 02:41:32 -0500 In-Reply-To: <20081114182718.e93352c3.sfr@canb.auug.org.au> Sender: linux-next-owner@vger.kernel.org List-ID: To: Stephen Rothwell Cc: linux-next@vger.kernel.org, Peter Zijlstra , Ingo Molnar At Fri, 14 Nov 2008 18:27:18 +1100, Stephen Rothwell wrote: > > [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. Heh, don't take too serious. I was just too nervous when I saw two build error mails just after waking up in the morning ;) Should have taken a pot of healthy caffeine before checking mails, at least. BTW, what would be the best fix? To me, the easiest is to revert the commit. But, if other HRTIMER_CB_IRQSAFE_* flag is known and confirmed to work like HRTIMER_CB_IRQSAFE, I can simply change to it as a fix. > > 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 ... Yeah, but in this case, really funny. The very same moment I did something dirty, suddenly spotted a light and taken onto the stage :) But, seriously, it'd be really helpful if clean-up patches are put on linux-next for a while just for testing purpose, too. thanks, Takashi