On Tue, Nov 13, 2007 at 07:57:54AM -0800, Ray Lee wrote:
> On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <cate@xxxxxxxxxx> wrote:
> > As a long time kernel tester, I see some problem with the
> > newer "new development model". In the short merge windows,
> > after to much time, there are to many patches.
>
> I think the root issue there is that it's hard to get all testers to
> run a bisect, but easy to ask them to test snapshots. Right now the
> snapshots are generated nightly, but I think it would make more sense
> if they were generated every N patches, for some value of N...
>...
I don't see a point in doing that - that would be a more manual
bisecting, and the result would not be one guilty commit.
Testers are not expected to be able to hack a kernel, but it's
reasonable to expect testers to be able to build their own kernels
(and your proposal wouldn't change that).
The small instruction below is enough for everyone who is able to
build his own kernel to do a git bisect.
> Ray
cu
Adrian
<-- snip -->
# install git
# clone Linus' tree:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# start bisecting:
cd linux-2.6
git bisect start
git bisect bad v2.6.21
git bisect good v2.6.20
cp /path/to/.config .
# start a round
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round
After at about 10-15 reboots you'll have found the guilty commit
("... is first bad commit").
More information on git bisecting:
man git-bisect
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
