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 [1]
- 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) [2].
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
[1] And if we fail there, feel free to remind us by email or on IRC.
[2] Outside situations covered by the current NMU rules, which I feel are
entirely sane.
Attachment:
pgplRwcA51l_v.pgp
Description: PGP signature