Re: [git patches] 2.6.x libata updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux