[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Too much disruptive NMUs



Quoting Ana Guerrero (ana@debian.org):

> I know this is done with the best intentions but if you think the package 
> is in bad shape or neglected by the maintainer then it might better write 
> to mia@, debian-qa@ or open a bug asking whether the package should be 
> orphaned (or even removed). Both examples below are candidates to be orphaned.

I have many of these in the packages I do NMU for l10n purposes.

My current policy is to fix my initial goal (debconf l10n) and a few
"obvious" QA things, by drawing the line to things I judge as
"enough non-disruptive":

- fixes in debian/copyright (GPL-2, missing complete copyright
statements...)
- ${misc:Depends} in dependencies
- move to "1.0" source format mentioned explicitly (I think that "3.0
(quilt)" would be "too much")
- when debhelper compat is 4 or below, either:
  - bump it to 5 if the packaging is tooc complicated for me to
  investigate
  - bump it to 7 with minimal changes (usually "dh_clean -k" ->
  dh_prep) for simple packages....and doing a little bit more check
  that it doesn't break anything (it generally doesn't as I of course
  do *not* change anything else in debian/rules)
- "_Choices" -> "__Choices" in debconf templates
- "Homepage:" in debian/control
- and any other lintian warning I consider "safe" to fix ("safe"
usually means that I am able to fix it in a couple of seconds...because
this is a change I already did in many other packages)


I do this because I regard l10n uploads (NMU or not) as QA uploads
already anyway.

I keep a full reference of packages I NMU'ed and I intend to spend a
few days in a near future in sending a notice to the MIA team about
those packages I NMU'ed this way without any sign of life from the
maintainer.

Several of these packages looks very loosely maintained. There, it's
harder to say whether there abandoned or not or if they should be
orphaned. I personnally see my own NMUs as a sign that the package
might be a good candidate for orphaning|removal..... Still, most
often, these packages don't have many bug reports....they just seem to
be living their life quietly in the archive without much need for attention..:-)

Attachment: signature.asc
Description: Digital signature


Reply to: