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

Re: Requests for sponsors to upload NMUs

On 2008-03-05, Neil Williams <codehelp@debian.org> wrote:
>> of course is changing SONAMEs in a NMU appropriate if it is appropriate.
> That equates to a hostile hijacking. If the package is orphaned or if
No it don't. it is just bugfixing. If it requires binary incompatible
changes to fix it, of course the SONAME should be changed as well. Else
you introduce new bugs.

> the maintainer is MIA and the package can be orphaned beforehand, fine
> (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is
> *not* acceptable in an NMU without permission from the maintainer. It is
> an especially bad idea when doing NMU's as part of a release bug

You seem to be living in perfect-world where maintainers are always

MIA-process && orphaning is too slow for bugfixing.  This isn't about
anything else than bugfixing.

> Adding a patch system is also not acceptable in an NMU. Neither is
> converting from dpkg to debhelper or CDBS or any other build system,
> even if, in your opinion, it would help the package overall.

That's not bugfixing, but changing packaging style.

>> yeah. let us not improve the package quality in debian.

>> Sponsors, keep up your good work.  If the changes are big, please
>> consider DELAYED/something though.
> That's worse! There is a day NMU bug squashing party in effect so there
> is no point uploading to the delayed queue. Just don't make hostile or
> intrusive changes in an NMU. Stick to the NMU rules.

fix bugs. Don't make debian the distribution where bugfixing other
packages is forbidden.  We need better packages. don't stop people
working for this. With delayed/7, you still have 7 days to react.

> An NMU is not a normal upload. Everyone doing NMU's *must* work with the
> current maintainer *or* the MIA process.

If the current maintainer is busy with real life, that is not possible.
MIA-process takes long time. 

> Do not delay RC fixes by adding unnecessary cleanup changes.
> Do not delay RC fixes by implementing a patch system if the package does
> not use one.
> Do not delay RC fixes just to remove a few lintian errors or warnings.

Please fix bugs.

> Keep the NMU clean and make sure the entire patch is in the BTS before
> seeking a sponsor or making the upload.

Of course make it nice, clean, well-documented

 - who wanted to track down a rc bug before sending this. It ended up
   with kdetv build failure.

Reply to: