At Fri, 18 Jul 2008 15:49:20 +0100, Russell King - ARM Linux wrote:
On Thu, Jul 17, 2008 at 12:05:43PM +0200, Takashi Iwai wrote:
At Wed, 16 Jul 2008 22:10:09 +0200, Marek Vasut wrote:
Dne Wednesday 16 of July 2008 13:17:53 Takashi Iwai napsal(a):
At Mon, 14 Jul 2008 16:07:58 +0100,
Mark Brown wrote:
On Mon, Jul 07, 2008 at 05:58:32PM +0200, Takashi Iwai wrote:
Doesn't matter much to me, so just let me know to merge via which tree.
Either way it needs another spin of the driver so...
OK, it's fine to push it to ALSA tree. But I think it's a bit too late for 2.6.27...
wasnt merge window for .27 opened just a while ago ?
It doesn't mean to allow us to push any unreviewed/untested patches. Trivial or fix patches can go immediately, but a new driver code is a different story. In general, the new driver codes should be merged to the subsystem tree in a few weeks before the merge window.
We can't moan about it not having been exposed though - it first appeared on July 4th here, and July 5th on alsa-devel.
It has been reviewed by Mark Brown, and you yourself even said "so just let me know to merge via which tree." which sounds to me like you were ready to merge it - but just wanted to know _which_ route it was going to take.
So, to now come back and whinge about it being unreviewed and/or untested and about patches being submitted before the merge window is a little silly, don't you think?
Not quite. Merging to the subsystem tree doesn't mean to push the stuff to Linus tree "immediately" -- especially it's never been tested with that merged tree. And in general, the new stuff has to be built and checked via linux-next and/or mm trees properly before reaching to the Linus tree. So, unless it's properly checked through the whole usual process, one shouldn't expect much that it must be merged so soonish.
Oh, before someone misunderstands again: actually I'm willing to merge his patch soon when it's ready. My comment is whether to push for 2.6.27 now or not.
Anyway, my present position with my tree is that I'm not merging anything further into my tree until the remainder of the code queued up previously has been merged, which will only happen when the SPI tree is eventually merged (or I get fed up with waiting for that to happen and choose build time breakage over the correct merge ordering.)
The reason for this is simple - if I push a new tree out, the nice diff versions for non-git users of my tree will vanish, despite there being changes still in there, and I don't want a flood of "where's my changes gone? they aren't in Linus' tree and they aren't in the diffs." questions.
Well, changes over several areas are sometimes painful.
I still think the "right" order for this kind of changes (addition of new driver depending on a certain architecture) should be: arch-change -> driver-addition. So I've wanted to hear from your first.
Anyway, I don't care much now how it's going. I'll merge the driver part soon once after it's ready. That sounds like the most practical solution.
thanks,
Takashi