Bug#641155: pu: package mdadm/3.1.4-1+8efb9d1+squeeze1

[Michael Tokarev]

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 at 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