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

Bug#680693: unblock: qemu-kvm/1.1.0+dfsg-1



On 08.07.2012 20:41, Cyril Brulebois wrote:
> Michael Tokarev <mjt@tls.msk.ru> (08/07/2012):
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package qemu-kvm.  Please note that the package has
>> already been uploaded to unstable, because I incorrectly assumed it
>> is the way to go during the freeze time.  Please excuse me for that,
>> it was made due to my lack of understanding of the process.
>>
>> As I wrote in email on Jul-14 <4FD9FC84.3050906@msgid.tls.msk.ru>,
>> https://lists.debian.org/debian-release/2012/06/msg00370.html ,
>> upstream delayed the final release of next stable qemu-kvm version
>> due to a few last-minute regressions found there.  The actual
>> release happened 2 Jul, ie, after the wheezy freeze.
>>
>> I managed to upload a prerelease of the package before freeze,
>> numbered 1.1~z0+dfsg-1 -- in last 40 minutes before freeze,
>> when I returned from my vacation.  However, this was based on
>> a prerelease (which happened to become a release 2 days later),
>> and it had a few glitches which are now sorted.
>>
>> The new uploaded package is based on the actual 1.1.0 upstream
>> tarball, which is different from the "fake upstream" tarball
>> I had previously only in one file, KVM_VERSION, -- previous
>> version had an -rc4 in it, new version has proper 1.1.0.  So
>> the current orig.tar didn't really changed.
> 
> You really should have let the freeze-exception-granted version migrate
> to testing first. The diff between testing and unstable is *INSANE*. 

That version grew a bug which people were hitting often -- #679788,
thats the only reason I hurried up with the new version.  People
started upping severity exactly to STOP it from entering testing.
So there's no way it'd enter testing with this bug, even it if
has an easy workaround.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679788#29
for example.

>  1832 files changed, 290208 insertions(+), 110147 deletions(-)

Yes, this is because of the new upstream version.  During last
months I concentrated on the new upstream because they basically
forgot the previous release once new one comes out, and because
back-porting fixes (I'd need to backport about 10 of them already)
becomes very, well, unreliable.  This is exactly why I wanted
to get 1.1 into wheezy, and waited for the real release for too
long - this most likely my greatest mistake, but again, if I were
to push it sooner it is not obvious how it were for users.  The
amount of trivial but troubling-for-users bugs fixed recently
during pre-release testing is high.  If not my vacation whith
basically lack of internet access (which was very unexpected!),
I'd upload it before.

What I can say for sure is that I wont be able to support 1.0
version (which is currently in testing).  It will be difficult
already to support 1.1, due to the same reasons, but at least
the bugs already fixed in 1.1 are not needed to be backported.

[]
> What matters is the diff between testing and unstable, see comment
> above. :(

Well.  Let's remove it from wheezy when.  I can work it out in the
bpo, it will even be easier this way.  After all, I already carried
it for about 2 years from my site during lenny times.

Thank you for your time!

/mjt



Reply to: