Re: [Qemu-devel] What is the best git-way to add a new board?

[Peter Maydell]

On 28 May 2018 at 06:02, Philippe Mathieu-Daudé <address@hidden> wrote:
> 1/ how RISC-V boards got merged
>
>   Add devices individually,
>   finally add the board and default-configs/Makefile rules at once.
>
> PRO: commits are easier to cherry-pick/rebase
> CON: you can not test a single patch until applying the whole series
>      harder (less interest) to write qtests

I don't think this one has any real benefits over 1bis, below...

> 1bis/ example of the Smartfusion2 board
>
>   Variant of 1/, but also modify the default-configs/Makefile to
>   build each device.
>
> PRO: single patch can be test without much troubles,
>      unit/acceptance tests can be run without applying the whole series,
>      different people can work in parallel.
> CON: no integration test until the last 'board' commit
>
>
> 2/ Reverse Polish testing
>
>   Add a board stub (all devices as UnimplementedDevice) and Makefile
>   rule, then for each new device, replace the unimp board entry,
>     modify the default-configs/Makefile,
>     add unit/acceptance tests
>
> PRO: you can add an integration test since the first board commit :)
>        (enforcing Test Driven Development),
>      allow unpaid contributor to slowly push his work upstream
>        instead of painful rebases or his work lost by change of
>        interest or worth issues.
> CON: not acceptable by upstream except with good integration test
>      integration test might not be upstream-able due to license
>        incompatibilities (JTAG-extracted firmwares...)

I usually go with some mix of 1 and 2, so for the first
patchset upstream I have a board model and a few devices
and the rest are stubbed out, but within that series I
put the device models first and the board model last.
While I'm doing the development before sending I might
well have started with more stubs than the final version
I send out has.

It's also worth distinguishing between the shape of the
commits you send upstream (which should be optimized
for code review, for being a coherent but not oversized
patchset, for not breaking compilation midway through the
series, and so on), and how you work on them before you
send them out. You don't have to start writing code with
the first patch in the set :-)

thanks
-- PMM