Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 08.05.2012 16:24, schrieb Anthony Liguori:
> On 05/08/2012 09:10 AM, Andreas Färber wrote:
>> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> rc0 is available, but patches submitted for 1.1 shortly before rc0
>> neither got review nor were applied. Neither did pulls or patches
>> applied by Anthony get such a notice fwiw so that it's hard to
>> distinguish what's missing for anyone but the patch author.
> 
> All pulls got handled before -rc0 was tagged.

OK, so if you want pulls for particular maintainer-less patch sets, then
please someone say so as a reply.

>> With rc0 not being provided as tarball, it would be nice to document the
>> official, reproducible way of packaging a QEMU tarball on the Wiki. I
>> have collected some steps from the Rob Landley mips thread, but the
>> submodules complicate things a bit.
> 
> -rc0's are never provided as a tarball.  This is how the release process
> works and someone always complains about it :-(

It was not a complaint about a missing tarball. I know from 1.0 that
there isn't one. But in order to prepare packaging for rc1 I find it
useful to start working with rc0 as a test run because it takes time.

My request (not complaint) was for you to document how you create the
tarballs you publish, so that the adventurous can create them without
bothering you. :)

>> rc1 should've been released yesterday, but it's not available yet, no
>> info and same issue with patches not being applied.
> 
> I missed a flight yesterday and spent the entire day at an airport so I
> didn't tag it yesterday.  I'm going to work on it today.

I can live with a tag or tarball being delayed, the issue is patches
people invested time for QA on don't make it into those tags.
This includes valgrind fixes from Stefan, mingw32 warning fixes, my
copyright and configure patches, one QOM CPU cleanup and possibly others
I'm not tracking. Unhandled pulls as well.

>> In the current state of master, rc1 will not build on ppc due to an
>> #error introduced since rc0 by malc - with its history, Darwin/ppc
>> should not be a release blocker here and *some* fix to restore the build
>> should please be applied soon.
> 
> So... what's the fix?

There's three patches floating around, one in the sparc-softmmu
unassigned memory thread, newer ones in a series of mine, and malc is
bouncing build fixes due to minor issues and his inability to test on
Darwin/ppc. I can send new patches for sure, but rather than spending
time on finding a perfect solution, as a SUSE employee, I'd much prefer
to fix the build issue first (and be it by reverting the troubling
#error commit), fix the register issues for Linux and optionally fix
them for Darwin and AIX. Further, the first patch from my series was
already confirmed correct by malc and could've been applied for rc1 but
wasn't (don't care about that one personally though).

What I'm criticizing here is lack of awareness of what milestones we
break by applying or not applying patches. What good is a Hard Freeze if
we wait with applying patches to the last milestone so they hardly get
any testing or if we postpone all fixes to an orphan stable branch?

Andreas

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