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]
