On Sat, Apr 12, 2008 at 10:41:44AM +0200, devzero@web.de wrote:
quoted text
> >Sure. It's not about bisection specifically, but about the time a
> >reporter is able to invest in addition to what went into the report
> >already. But bisection is is a good example, because it's the most
> >time-consuming of all the tasks routinely asked from bug reporters.
> 
> i think the problem with git-bisect is, that it just apears complicated and magic for an end-user. 
> this isn`t something a kernel-developer can explain to him in a sentence (i.e. how to use etc)
>...

When I ask a user to bisect, the standard boilerplate I give to the 
user is:

<--  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

<--  snip  -->

In my experience users are able to bisect with this boilerplate
(unless there are problems like e.g. other regressions hit 
during bisecting).

quoted text
> regards
> roland
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/