Next time you think about doing an NMU make sure it is fully
functional. Even the NMU you did would have failed to build on arm, m68k
and hppa. I have spent the past 48 hours working on the proper fix for
it. My current 2.0.7-3 doesn't even fix it yet and you're NMU didn't
even come close.
I knew the upstream release was secondary to the transition. Had you
taken proper attempts at communication with the maintainer you would
have been able to determine the issues I was already working on before I
dealt with the new version.
I fail to see how you're jumping the gun did anything to help. The
only package currently held up with the libfwbuilder package issue is
fwbuilder itself. So it was not holding up the Qt/KDE transition. You
also failed to even acknowledge #323133, which by itself was not
directly apparent from the bugs you attempted to close, that has a
direct impact on the build. If you only built on i386 or any other arch
besides the three it affects you would not have known that unless you
had actually had some communication with me. Instead you were impatient
to get went ahead without all the facts in the situation.
Next time I would appreciate you not NMU *ANY* of my packages
without direct direction to do so from me, the DPL or the release
manager as you obviously failed to research the situation.
Regards,
Jeremy
Luk Claes wrote:
>Jeremy T. Bouse wrote:
>
>
>> Next time I would appreciate it if you followed section 5.11.1 of the
>>Developers Reference a bit more closely.
>>
>> You did submit a bug report, atleast the snmp dependency was one that
>>actually did not already have a report submitted on; however giving less
>>than 24 hours before you uploaded not only the NMU but the patch to the
>>BTS hardly gives time for a response from the developer. Submitting the
>>patch within 24 hours and not uploading the NMU after giving some time
>>for a response would have been better.
>>
>> 5.11.1 states the following order, please abid by it:
>>
>> 1) File a bug report *Hurray you did that atleast*
>> 2) Wait a few days for a response. File a 'patch' if no response
>> 3) Wait a few more days if you get no answer, then mail announcing
>>the intent to NMU
>> 4) Upload your package to DELAYED/7-day (not 3-DAY, not 5-DAY,
>>*7-DAY*)
>>
>>
>
>It's part of the gcc and Qt/KDE transition. At least for libfwbuilder
>3-DAY is apropriate... Open RC bugs are an intent to NMU... and an NMU
>is no attack, it's just to help you...
>
>
>
>> If you had checked all the other bugs you closed and read them you
>>would have noticed that I was working on the 2.0.9 packaging already as
>>it had been released. I had been working on 2.0.8 when the C++ ABI
>>transition hit the mirrors. You would have also noticed I respond to
>>just about every bug report filed, so not getting a response from a bug
>>filed within 24 hours isn't a problem.
>>
>>
>
>Fixing RC bugs is more important than a new upstream...
>
>
>
>> I won't go on about the fact that some of the items in the bugs you
>>closed were not addressed in your NMU to begin with and would have been
>>closed without being addressed.
>>
>>
>
>You mean the bug that was already fixed, but not closed by you?
>
>
>
>> Checking the QA mia-history would have also showed I wasn't MIA as
>>well; however you made no attempt, other than the one bug report to,
>>contact me prior to doing the NMU.
>>
>>
>
>Note that the NMU has not reached the archive yet and that your packages
>are holding the Qt/KDE transition... The other option next to NMUing was
>asking its removal from testing in a couple of days...
>
>Note also that NMUing is to help you. I'm sorry if you misunderstood
>this NMUs as an attack. The procedure for NMUing described in the
>Developers Reference is indeed a good one for fixing random bugs, but
>please understand that it is too much hassle for a testing migration of
>a *big* transition.
>
>So, sorry again if it came over as an attack.
>
>Cheers
>
>Luk
>
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
