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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
