Hi, On Sat, Jul 29, 2006, Anthony Towns wrote: > What if we introduced the concept of "area" maintenance? Like saying > "Matthew Garrett is part of our hardware support team, so can thus NMU > any package that needs changes to support that release goal."
Can you give other use cases than hardware support? I think it would be a great idea if it were applied to cross-package integration in general, not to specific task in particular. I am not sure I would like a static list of areas/teams such as hardware support team, security team, GNOME team, etc.; but I would appreciate temporary special powers for e.g. transitions or implementation of a spec people have agreed upon, some examples: - 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) - use of alternatives for a new class of programs (for example, a team would change all SVG capable editors to add a svg-editor alternative) - use of a new configuration framework for SSL services (for example, a team would integrate the necessary hooks in all maintainer scripts) - use of a new tool when building GNOME packages (for example support for cache files in icon directories, a team would NMU to add the required debhelper foo) So, more a "spec -> validation -> team -> NMUs" workflow than giving superpowers to some developers in some areas. It seems to me Ubuntu relies on spec heavily, and Launchpad seems to offer some sort of framework which Ubuntu folks combine with Wiki pages to: - write the spec - propose the spec - validate the spec Specs seem to have an urgency (what we could release goal I suppose), and a supervisor. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]