Re: [Qemu-devel] [PATCH 11/13] Move pci_parse_devaddr to qdev-properties

[Andreas Färber]

Am 08.06.2012 15:55, schrieb Anthony Liguori:
> On 06/07/2012 08:57 PM, Andreas Färber wrote:
>> Am 04.06.2012 10:52, schrieb Jan Kiszka:
>>> We will some use this function also for property parsing, so move it
>>> over unmodified and rename it.
>>>
>>> Signed-off-by: Jan Kiszka<address@hidden>
>>
>> These last three patches collide with Paolo's QOM properties
>> refactoring: qdev properties are being generalized to Object and on my
>> GitHub "realize" branch are being moved to qom/object-properties.c
>> (object.c in the original series). Please defer this change.
> 
> Sorry, this doesn't scale.

Jinx! :)

> Patches need to go in when they're ready.  If that means someone branch
> has a hard time rebasing, it probably means that branch should have
> attempted to merge sooner.
> 
> If you want to work out the issues earlier, then setup a next branch or
> something like that.

We *are* talking about qom-NEXT here! It serves exactly that purpose, to
have a known location for people to rebase on and to avoid conflicts.
Jan was ignoring that, I'm guessing because he doesn't read qemu-devel
unless cc'ed. And in turn I don't consider it the duty of the qom-next
maintainer to check everyone's submission for possible fumbling in
qdev/qom code and rebasing onto every random open PULL. (Note that I'm
not complaining about properties being added in some random file, I am
specifically annoyed about refactoring in hw/qdev-properties.c after
these series have been around for like two months and after I officially
announced the branch as requested by you.)

And let's not forget that a certain release manager promised to talk to
me/us about the post-1.1 merge plan after rc4 but then instead decided
to fold rc4 and final and opened up the master branch without discussing
any merge strategy, contributing to this chaos. The way you are handling
it, it is totally unclear for submaintainers in which order series are
going to go in. So either we need to coordinate PULLs among each other
as attempted here, or you as maintainer need to volunteer to merge such
conflicting PULLs yourself and not just bouncing them.

Anyway, some people need to take care of packaging the tarball after
it's released and your part in the release process is finished. That
takes time, and your change of schedule stirred my time planning for a
whole week. ;)

Plus a contributor to qom-next surpassing himself with another invasive
refactoring that you wanted to fast-track wasn't helpful either.

Not to mention that this is also connected to a nack of yours for which
we still don't have a solution, while the original author is on travels.

So yes, I could have started merging qom-next earlier (e.g., had I taken
the decision to split it earlier) and you could've supported that effort
better through early review, better planning and better communication.

> But don't expect someone else to hold up there work just because it
> conflicts with yours.  That kind of ordering won't scale in a community
> as large as ours.

I am only one and cannot rebase onto every open pull request, especially
not for a branch that was only meant to bridge the imposed Hard Freeze
and should thus go away quickly because no longer needed.

If it were a private branch/series of mine then that would be a
different matter of course.

Nevertheless conflicts do happen and need to be resolved by someone. If
you are volunteering, so that I don't have to speak up, that's fine with
me. But saying that ordering doesn't scale in a community is not solving
the problem.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg