On Mon, May 24, 2010 at 09:48:27AM +0200, Lucas Nussbaum wrote: > On 24/05/10 at 09:31 +0200, Ricardo Mones wrote: > > > > Hi Lucas, > > > > [Though not very active, I'm subscribed to QA ;-)] > > > > On Sun, 23 May 2010 19:22:07 +0200 > > Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > > > > > On 23/05/10 at 12:32 +0200, Ricardo Mones wrote: > > > > On Sun, 23 May 2010 08:40:44 +0200 > > > > Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > > > > > > > > > > This one is not even fixing a serious bug: > > > > > > > > > > So? NMUs are not only for serious bugs. > > > > > > > > Then, as Ana said, the developers reference should be changed because > > > > that's just the opposite of the first point in 5.11.1 "When and how to > > > > do an NMU": «Does your NMU really fix bugs? Fixing cosmetic issues or > > > > changing the packaging style in NMUs is discouraged.» > > > > > > I think that this should be read as "NMUIng when your only changes are > > > cosmetic issues is discouraged". If you are doing an NMU anyway (to fix > > > a real bug), I don't think that it should be discouraged to fix other > > > small issues at the same time, if those changes are reasonable. > > > > At this moment those small issues (if we take the original posting > > examples) are not issues at all but packaging preferences and > > lintian I/W tags (most of them). > > Most of them. But both uploads also included real bug fixes. I didn't say the contrary, just talking about the "small issues" going in with them. > > While is perfect to have them cleared, I think a lot of active > > maintainers would complain if you change that when fixing a bug in > > NMU, because that's not the point of a NMU. > > In those examples, the maintainers are inactive. Let's stick to the > cases we have, and let's not start about "what if the maintainer was > active?" I thought the discussion was about general usage of NMUs as QA uploads for non-orphaned packages, not just this two examples. > > Only inactive don't > > because they don't really care about the package. > > parse error ;) +complain > > That should be > > telling them it's the hour of taking care or orphaning the package, > > and so they should be informed. The NMU way, even if done correctly, > > only hides the real problem here. > > No. The real problem is the quality of our packages, not the fact that > some maintainers are less active than others. Of course, it would be > nice if every package had a maintainer that care about it, but that's > just not possible, and I don't think that most of our users care. I've always assumed maintaners work for improving their packages, so the quality of them is directly related with maintainer activity. Name it as you wish, but in the end the problem is the same :) > NMU is a quick and easy process to improve the quality of neglected > packages. We have other processes, like MIA and the "should be package > be orphaned/removed?" process, that enable to switch maintainers when a > maintainer is nonresponsive. Those processes are much longer, and do not > result in an immediate increase of the quality of packages. So the right > thing to do, in the case of Jari and Nobuhiro, is to NMU _and_ make sure > that the MIA process is going on for those maintainers. Which is what > they did. So we're back at what I said in the other mail: if those processes we already have take too long let's shorten them and make those neglected packages fall under QA umbrella faster, do not use NMU as a general procedure because a NMU it's not the thing for that. And if you think it's adequate to NMU it should be clearly stated in the relevant documents (notice I'm not against any of both options), otherwise an immediate increase of some packages' quality could bring a decrease of our inter-maintainer relationships quality on the long term for using NMUs for workarounding such processes. That doesn't mean Jari and Nobuhiro had done anything wrong in this case. regards, -- Ricardo Mones ~ RTFM - "Read The Manual" (The 'F' is silent). Usually a very good idea. Bjarne Stroustrup
Attachment:
signature.asc
Description: Digital signature