qemu-devel
[Top][All Lists]
Advanced

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

RE: [Qemu-devel] State of EHCI emulation for QEMU


From: David Ahern (daahern)
Subject: RE: [Qemu-devel] State of EHCI emulation for QEMU
Date: Wed, 8 Dec 2010 09:41:43 -0800




-----Original Message-----
From: Gerd Hoffmann [mailto:address@hidden]
Sent: Wed 12/8/2010 10:14 AM
To: David Ahern (daahern)
Cc: Jan Kiszka; qemu-devel; Jes Sorensen
Subject: Re: [Qemu-devel] State of EHCI emulation for QEMU


   Hi,

> Where was the messiness given that most of the changes are to a brand
> new file?

 From the "devel -> merge with upstream -> fixup breakage + commit ->
devel" cycle.  When rebasing *that* you simply don't get a nice +
bisectable patch series.  Early patches didn't apply cleanly due to
buildsystem changes.  After fixing up that ehci didn't build.  Of course
there are likely fixup patches coming later which solve that which I
could try to find + cherry-pick + squash-in.  But at that point I felt
it simply isn't worth the trouble given that we would squash it all
together anyway for patch review + upstream merge.

cheers,
   Gerd


New features developed for the kernel are done in a separate git trees. When a feature is ready for inclusion into the main kernel tree, a pull request is sent. That workflow maintains a complete change history for the feature. Take performance events for example: you can go into Linus' git tree and see the complete history of changes. There's no reason the same methodology cannot be done for qemu.

David


reply via email to

[Prev in Thread] Current Thread [Next in Thread]