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.1020...@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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6c5943.90...@msgid.tls.msk.ru
