qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 36/37] qdev: remove QDEV_PROP_PTR


From: Markus Armbruster
Subject: Re: [PULL 36/37] qdev: remove QDEV_PROP_PTR
Date: Mon, 06 Jul 2020 14:03:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Philippe Mathieu-Daudé <f4bug@amsat.org> writes:

> On 7/6/20 12:01 PM, Marc-André Lureau wrote:
>> Hi
>> 
>> On Mon, Jul 6, 2020 at 12:44 PM Philippe Mathieu-Daudé <f4bug@amsat.org> 
>> wrote:
[...]
>>> Yet another sneaky way to force forks to either update to QOM or die...
>> 
>> You can't blame upstream from doing cleanups and modernization, or
>> stagnating. Forks are forks, with all the pain they carry. If they
>> want to avoid the maintenance cost, they have to do the extra effort
>> to get it upstream. This is also a "sneaky way" to remind them that
>> effort is better spent in this direction.
>
> I totally understand, but at the same time we are excluding hobbyist
> contributors with mainstream exigency.
>
> This is unfortunate. I'd like to suggest ideas how to keep the QEMU
> project open to non-corporate contributors, but I don't have any.

Anyone with a fork to rebase continuosly is in an unenviable position.
Rebasing will never be painless, and the only way to win the game is to
stop playing it, ideally by getting your stuff merged upstream.

I think this is related to hobbyist vs. corporation only insofar a
well-heeled corporation can fund folly for much longer than a hobbyist.

That said, helping forks bear the rebase pain while they work towards a
merge is certainly a laudable goal.

> Well, maybe this one: better document API changes, if possible with
> examples (example can be as simple as pointing to a particular commit
> sha1). At least for each release, because forks usually try to rebase
> after releases.

Yes, release notes for developers would be nice.




reply via email to

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