On Fri, Oct 22, 2004 at 11:03:18PM -0700, Steve Langasek wrote: > I'm very concerned by the number of changes included in this NMU, not even > counting the new upstream version. The release-critical bugs *must* be
The NMU does not include the new upstream, I was just suggesting that as a possibility, since the new upstream is only bug-fix-related. Maybe users have been bitted by these bugs but they have not been reported. > resolved before release, and attempts to fix other, unrelated bugs in the > same upload stand a very good chance of introducing new RC bugs and keeping > the package out of testing. Especially since you say this patch is > untested, it also makes it more questionable to approve pushing such a > changeset past the freeze without giving it the full 10-day waiting period. I don't really know how much time we are from a release, but I wouldn't mind if the NMU went through the 10-day waiting period (even more, if possible) and _then_ was pushed past the freeze. I'm not asking for the NMU to be pushed in to sarge without further testing. I'm concerned, however, about d-i. Do any of the changes below affect d-i? In any case, I am quite aware that fixing other bugs might introduce new RC bugs, however, please notice that there are only three type of fixes in this NMU (even if the changelog is rather verbose): - Documentation fixes (i.e. patches to manpages and/or new translations), these have a _very_ slim chance of introducing new RC bugs. - Aliases changes (i.e. changes to debian/conf/aliases and util/alias.h) these should also be safe, but there might be issues related to these. These changes are needed to fix the RC bugs. - Changes to scripts (update-modules), these include fixes for long standing bugs (such as #166531, required by Joey) that might even be an issue when upgrading from previous releases, take a look at #69754, #220382 and #253508. These have a higher chance of being an issue, but, if you take a look at the patch provided, the changes are really small and should be easy to review & test. > Please consider limiting your NMU changeset to those changes required for > fixing the RC bugs. I wanted to take the opportunity of doing some cleanup of rather trivial issues which should not break the package. I'm open to doing a NMU only to fix RC bugs but then sarge will not benefit from this cleanup. Consider the following diffstat: debian/changelog | 55 +++++++++++++++++++ debian/conf/aliases | 121 +++++++++++++++++++++++++++++++++++++++++- debian/control | 7 +- debian/modules.es.5 | 18 ++++++ debian/modules.fr.5 | 15 +++++ debian/modules.pt_BR.5 | 11 +++ debian/rules | 21 +++++++ debian/update-modules | 13 ++-- debian/update-modules.8 | 22 ++++++- debian/update-modules.es.8 | 92 +++++++++++++++++++++++++++++++ debian/update-modules.fr.8 | 93 ++++++++++++++++++++++++++++++++ debian/update-modules.pt_BR.8 | 88 ++++++++++++++++++++++++++++++ util/alias.h | 34 +++++++++++ The only changes to code there affect update-modules and alias.h. All other changes are l10n-related (even the changes to debian/rules) or documentation related (manpage changes) I will keep on fixing bugs in modutils, and will (that's for the Release Team and the Maintainer to decide) either NMU with all of them or NMU with just RC fixes, wait a few weeks, make sure RC fixes are in sarge, and then NMU with all other fixes. I would also be interested in hearing's LaMont opinion on this changeset, after all, he is the maintainer and might have a better idea than the chance of my fixes ending up being RC bugs [1] Regards Javier
signature.asc
Description: Digital signature
