Bug#641155: pu: package mdadm/3.1.4-1+8efb9d1+squeeze1
On 11.09.2011 02:09, Philipp Kern wrote:
> On Sun, Sep 11, 2011 at 01:09:35AM +0400, Michael Tokarev wrote:
>> We'd like to upload a bugfix release of mdadm package for the
>> next squeeze point release. There are mostly cosmetic changes,
>> but some of the bugs are very annoying and already made quite
>> some users unhappy - like the famous #598957, when mdadm monthly
>> cron job generated useless email messages about i/o scheduling
>> class for monthly array checks -- this bug alone prompted several
>> NMU attempts already.
>
> See <4DBFA62F.1020404@debian.org> ff. We require changes to be in unstable
> first. We really do.
Understand. It was my biggest concern actually, I didn't think it is
a good idea to go stright to stable without being in testing first,
even with the trivial changes this set.
> So fix "your" package in unstable, let it be tested, and we'll look at it. So
> far all attempts have targetted stable only, which is the wrong approach.
So, what's the right course of actions here? Yesterday we were about to
upload a more recent upstream version to unstable, with all the fixes and
alot more.
Now, I'm not sure it is a good idea anymore, since that version will not
go to squeeze obviously.
So I have to upload this "squeeze1" version to unstable, with one added
ugly fix for ftbfs with gcc-4.6. Ugly because I don't want to apply a
more intrusive patch in order to fix -Wunused-but-set-variable (which
are all harmless) when targetting _stable_, instead I will have to remove
-Werror from the upstream makefile and let it build on _testing_, -- just
because I finally want it to appear in stable.
And once accepted into stable with this ugly change, I'll immediately revert
that -Werror change and upload new upstream into unstable.
Is that the right approach?
And what if we already had new upstream uploaded into unstable/testing?
I'm not complaining, I'm just trying to understand the rigth way... ;)
Thank you,
/mjt
Reply to: