qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/15] AHCI test helper refactors


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 00/15] AHCI test helper refactors
Date: Fri, 19 Sep 2014 13:57:00 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Sep 19, 2014 at 12:53:22PM +0200, Markus Armbruster wrote:
> John Snow <address@hidden> writes:
> 
> > The original version of the AHCI test base
> > which is now staged for being merged, processes
> > the ahci_identify test in a monolithic fashion.
> >
> > In authoring new tests, it became necessary and
> > obvious as to how the operation of this device
> > should be factored out to ease the writing of
> > new AHCI tests.
> >
> > This patch set issues the necessary refactorings
> > to support future test development for AHCI.
> >
> > This patch set DOES NOT account for any new fixes
> > and requires no fixes from my "AHCI fixes" RFC
> > in order to run successfully on 2014-09-18's
> > origin/master.
> >
> > This patch set does not alter the operation of the
> > existing test, or add new tests. It only offers
> > refactorings for future patch submissions which
> > depend on them, but are still under consideration.
> [...]
> >  tests/ahci-test.c | 860 
> > ++++++++++++++++++++++++++++++++++++------------------
> >  1 file changed, 583 insertions(+), 277 deletions(-)
> 
> Ignorant question: why should we commit the "monolithic" test only to
> refactor it extensively right away?

The patches merged in the block tree have been fully reviewed and
tested.  It took a long time to reach that state.

I don't want to go back to square one and have to re-review it all.
Refactoring is mechanical and therefore easy to review.

The earliest we can merge this new series is next week.  Let's not try
to make it perfect if that means building up a monster series over many
weeks.  Let's merge incrementally and keep moving.

(I do believe that clean commit history is important and patches should
be polished, but in this case work spans too long to keep redoing it
all.)

Stefan

Attachment: pgpCCK6zhWlu4.pgp
Description: PGP signature


reply via email to

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