On Tue, 2009-10-06 at 08:13 -0700, Linus Torvalds wrote:
quoted text
> 
> On Tue, 6 Oct 2009, Dirk Hohndel wrote:
> > 
> > I respectfully disagree.
> 
> .. because you don't know what the f*ck you're talking about.

Always a pleasure having an intellectual discourse with you.

quoted text
> > With the proposed -rc0 there is EXACTLY ONE kernel that is called 2.6.31
> > - the release kernel. And everything else is called something
> > 2.6.xx-rcY.
> 
> No.
> 
> That's simply not _true_.
> 
> Think it through. Deeply. 
> 
> In particular, think about all the developers who start out at known 
> stable points. And they are _supposed_ to start at release points. It 
> means that a lot of versions in the -rc window will NOT have that -rc0 in 
> them.
> 
> In fact, even more commonly (for people who don't rebase, which should be 
> the default), you'll have kernel versions in the merge window (and later) 
> that will have Makefiles that talk about the previous release.
> 
> If you can't get that FUNDAMENTAL FACT, then I don't know what to say.

The fundamental difference in our analysis is that I believe that 1% of
the people using these kernels are developers as you describe above and
99% are people who pull from your tree and build and test.

quoted text
> > So if you see something that identifies itself as -rc0, you know it's
> > from during the merge window. If you see something that calls itself
> > 2.6.xx then you know it's a release kernel.
> 
> No. No. And NO.

For people simply pulling from your git tree, I think the answer is YES.

quoted text
> Your kind of magical thinking leads to _problems_. It's literally been a 
> problem that people stop bisecting, because they notice that they start 
> testing kernels that have a version number before the release they already 
> tested as good. Exactly because of your kind of linear thinking.

I think those two things are entirely unrelated. How would calling the
versions in the merge window -merge or -rc0 make any difference
whatsoever in whether people are confused by git bisect behavior?

quoted text
> We need _less_ linear thinking, not more. And you need to start thinking 
> about other kernels than just my release tree.

I do - I actually track multiple trees and have my own in which I do my
own work.

That still doesn't change my believe that the VAST MAJORITY of the
people out there only track one tree. Yours.

But hey, as you have stated so eloquently, I "don't know what the f*ck
[I'm] talking about", so let's hear what others are thinking.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/