Re: Bug#659045: RFS: goplay (NMU)
Hi Arno,
On Wed, 8 Feb 2012 04:10:48 Arno Töll wrote:
> > + compat and debhelper to version 9 + default hardening (with the
> > exception of fortify) + standards to 3.9.2 + ept-cache replaced
> > with apt-xapian-index in Depends
>
> We don't do such things in NMUs.
>
*Sometimes* we do.
The options are:
* QA : Not in this case since the package is team-maintained.
* Team : Looks like best option, but I'm not the team member
so I can't upload on behalf of the team.
* NMU : Certainly not an unreasonable option, read below.
Of course team upload would be the best but because package hasn't been
touched for years, I have reasonable concerns that either team is not active
or they are busy with something more important.
Normally I would send patches but in this case I found no public repository
and not even upstream repository.
Because for few years there were no activity regarding the package (neither
package updates nor bug tracker activity) I think the NMU approach is
reasonable.
Changes in NMU are easy enough to acknowledge so whoever interested may just
drop my work in DELAYED unless team would step in.
> > (Closes: #615495 important:"goplay must be run as root at least
> > once to function") (Closes: #460921 wishlist:"requires manual
> > ept-cache reindex on the first start") + games-thumbnails moved to
> > Recommends (Closes: #470047 wishlist:"please Recommends:
> > games-thumbnails instead of Depends") + no longer depends on
> > g++-4.5 (Closes: #654733 important:"non-standard gcc/g++ used for
> > build...") + build-time .xpm icon regeneration, no longer ship
> > pre-built icon (imagemagick added to build-deps)
>
> And neither most of that.
I think sometimes you'd better consider common sense.
I believe you're not saying "don't do the best you can in NMU" because that
would be quite discouraging.
There are enough teams out there who do not accept anything less than perfect.
So I spent couple of hours doing those improvements and I've chosen to fix
what I could and then walk away to address other problems. This provides more
help regarding work needed and allow to use time effectively.
Let me point out that your concerns regarding what can be done in NMU would be
better considered in context of what's the best for the package and if the
changes are good enough for upload.
I've seen NMUs with bigger changes. NMUs are there to address problems aren't
they?
Also from technical prospective it is reasonable to use proven up-to-date
packaging since outdated packaging often cause problems by itself.
NMU should not be in the way of quality.
>
> Please keep NMUs minimally invasive and fix _very_ important bugs only
> (i.e. RC bugs or other important bugs which qualify for a NMU). See [1]
>
> [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
I'm aware of that, thank you.
Regards,
Dmitry.
Reply to: