On Mon, 31 Oct 2005, David Lang wrote:
On Sun, 30 Oct 2005, Junio C Hamano wrote:
Rob Landley <[email protected]> writes:
grep -n MARKER bisect.patch | less
(pick a line number)
head -n linenumber bisect.patch > test.patch
If that's not it, revert test.patch and then try again. Tell us the first
line number that failed, which is the end of the patch we want...
Hmmm... The logical place to put the URL to gitweb is at the _end_ of the
patch, attached to the marker. So that's what they see in the grep, and
the
last thing they test when they cut at that line with head -n...
Well, do people realize that 'git bisect' is *not* a textual
half-way between, but rather is computed every time you feed
new "the patch you told me to test last time was good/bad"
information? I do not think statically generating a huge text
and telling the user to apply up to halfway and bisect by hand
would not work -- it would be quite different from what git
bisect would give you.
I think public webserver based bisect service David Lang
suggests might work. The interaction with it would start by the
end user somehow giving it the last known-working commit ID (A)
(pick from gitweb shortlog, perhaps) and a commit ID newer than
that that broke things (B) (again, pick from gitweb shortlog).
Then the service runs bisect on the server side, spit out a diff
against (A). The end user applies the patch, try it, and then
come back and tell if it worked or not,... Since we are talking
about the kernel development, I think the cycle might involve
rebooting the machine; so you would probably need two machines
(one guinea-pig machine to reboot, another to keep the browser
open so that your state can be kept somehow).
given the time required to compile a kernel and reboot you can't plan to keep
the info server side (browser connections will time out well before this
finishes)
instead this will require saving something on the client and passing it back
to the server.
offhand I'd say that it would end up working something like this.
1. go to the website and pick starting good/bad points
2. the server will give you a tgz (bzip is significantly more load on the
server) that contains the patch and a status file.
3. apply the patch to the starting tree (in theory it may be a smaller patch
to either tree, but it's easier to explain if one is picked all the time so
initially it should be the working tree). compile the tree and test
4. go back to the website, upload the status file and indicate sucess or
failure
5. goto 2
the file would basicly save and report what git bisect would normally store
in environment variables.
the server will have to do some sanity checking on the good and bad points
it's given (for security reasons if nothing else)
potentially it should suggest checking an officially tagged release that's
between the good and bad points. this may actually slow testing slightly (if
you know it worked on 2.6.7 and failed on 2.6.12 you would probably be the
most efficiant if you start bisecting directly, but it's far easier for
others to understand things if you test 2.6.10 and other tagged releases
first)
I also suspect that a log of what people are testing would be intereating to
people as well (if you see a bunch of people bisecting in the same area it's
an indication that more attention needs to be paied to that area)
David Lang
an alternate approach that would be a little cleaner would be to use a
cookie to store the bisect state info so that it is just a patch that's
downloaded (although this does limit someone to bisecting one thing at a
time, I think that's not an unreasonable limitation)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
