-----Original Message-----
From: Gerd Hoffmann [mailto:kra...@redhat.com]
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
