From: Frans Pop <elendil@planet.nl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Linux 2.6.32-rc3
Date: Tue, 6 Oct 2009 18:36:01 +0200
User-Agent: KMail/1.9.9
Cc: hohndel@infradead.org, linux-kernel@vger.kernel.org
References: <alpine.LFD.2.01.0910041727310.3432@localhost.localdomain> <alpine.LFD.2.00.0910052140100.309@localhost.localdomain> <1254797502.14122.146.camel@dhohndel-mobl.amr.corp.intel.com> <alpine.LFD.2.01.0910060705240.3432@localhost.localdomain> <1254839931.24117.9.camel@dhohndel-mobl.amr.corp.intel.com> <1254839931.24117.9.camel@dhohndel-mobl.amr.corp.intel.com> <alpine.LFD.2.01.0910060808220.3432@localhost.localdomain>
In-reply-To: <alpine.LFD.2.01.0910060808220.3432@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200910061836.02726.elendil@planet.nl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2804
Lines: 61

Linus Torvalds wrote:
> 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 do understand your point, but I'm not sure that it makes sense to take 
bisecting as the main criterium here. Bisection will always be confusing 
for users the first few times, whatever you put in the Makefile.

IMO it is more relevant that people who build and run pre-rc1 kernels get a 
clear distinction by default between their stable kernel and the (highly 
unstable) merge window one.
When a user compiles a kernel, the only thing that's relevant is what's in 
Makefile *at that time*, not where the branches that are merged in happen 
to originate.

Personally I always add a -rc0 in a local commit as soon as I pull any 
merge window changes (that commit gets dropped when you release -rc1).
Package versions are derived from git describe.

So I get (examples include local commits):
linux-image-2.6.31_31.g5e9d407_amd64.deb (.31 + 31 local changes)
linux-image-2.6.31.1_31.gb4adf51_amd64.deb
linux-image-2.6.32-rc0_7396-g02b51df_amd64.deb
linux-image-2.6.32-rc1_20.ge8343d5_amd64.deb
linux-image-2.6.32-rc1_154.gb157421_i386.deb
linux-image-2.6.32-rc3_18.g7e921a0_amd64.deb
linux-image-2.6.32-rc3_69.g7146bc5_amd64.deb

Of course this it makes no difference if you use 'make install', but for 
other cases I think having -rc0 in mainline first thing in the merge 
window would be useful. Especially for users who compile kernels from the 
git tarballs during the merge window (and are not aware of localversion).
Of course there are plenty of options to do whatever you want locally, but 
why not make it easy?


BTW, I've got a solution for bisection too: the versions in the Makefile 
get changed to something constant. And the package version is set equal to 
the bisection iteration. This ensures that I know exactly which kernels 
were build for the series and that I can always go back to a specific 
kernel if I need to retest for some reason.

E.g. (for a bisection covering .30-.31):
linux-image-2.6.31-bisect_1_amd64.deb
linux-image-2.6.31-bisect_2_amd64.deb
linux-image-2.6.31-bisect_3_amd64.deb
...

Cheers,
FJP

P.S. I use the deb-pkg target to build all my kernels. A wrapper script 
takes care of all the stuff mentioned above (and cross-compiling). For me 
the clean package management is worth the slight overhead.
--
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/