On Saturday 29 July 2006 14:39, Loïc Minier wrote: > - introduction of udebs for a new feature of the installer (for > example, support of wifi drivers on a separate media, a team would > add udebs to the relevant packages, and change the relevant d-i > packages to support this) To be honest I don't think that in general NMUs are appropriate for packages (udebs) maintained in the d-i SVN repository by the d-i team. But it may be possible that you did not mean that for this case. In the example you give, it seems most likely that the changes would be initiated from within or by someone cooperating closely with the d-i team. Thus, the NMUs could possibly be done for the "regular" packages that need a udeb added. This has been done in the past, but AFAIK mostly with the prior consent of the maintainer. I would expect the changes in d-i itself to be done in SVN and released from there as regular uploads. There are several reasons why NMUs for existing packages maintained in the d-i SVN repository are not in general desired or even needed: - the d-i team is big and active enough that getting needed changes in should be possible without resorting to NMUs  - why do an NMU if an upload can also be done through the team and thus having the changes properly committed in SVN? - there may be valid reasons why a change is not wanted at a certain time; breaking the current release being one of them - NMUs are likely to break the way we credit translation updates in the changelog - changes in d-i are often more complex than they may seem at first glance; we regularly manage to break things ourself with seemingly innocent changes IMO NMUs should never be done for packages with a generally active maintainer (or team) without at least trying to get the opinion of the maintainer first (which implies allowing the maintainer sufficient time to respond) . This goes even stronger in cases where, like d-i, there is a separate subproject rather than team maintenance of a set of packages. In most cases it should be easy enough to determine if a package is being well maintained or has an active maintainer. Maybe we should base the NMU rules on that. Cheers, FJP  And if we fail there, feel free to remind us by email or on IRC.  Outside situations covered by the current NMU rules, which I feel are entirely sane.
Description: PGP signature