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

Re: Why does Ubuntu have all the ideas?

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 
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
- 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.


[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: pgpLREHaRbWQc.pgp
Description: PGP signature

Reply to: