[Pkg-javascript-devel] Request for policy interpretation: procedure and possible outcomes for naming conflicts

[Bill Allombert]

On Wed, May 02, 2012 at 02:12:22PM -0500, Jonathan Nieder wrote:
> Hi policy editors,
> 
> In the discussion at [1], Pat wrote to the DPL asking for some
> mediation in figuring out what should happen to the "node" command
> name.  No one has offered that mediation (the ctte presumably could do
> it if asked) but I mentioned that there seems to have been some
> uncertainty about matters of procedure[2], mostly revolving around
> policy §10.1 and the role of policy in general.
> 
> Stefano suggested writing to you to request interpretation of policy.
> Sorry to drag you into this.  Thoughts would be welcome, but if you'd
> prefer to hold off on interpretation until this particular story is
> resolved, that would be a fine answer, too.
> 
> The questions (from [2]):
> 
> - When policy 10.1 refers to maintainers reporting naming conflicts to
>   debian-devel and trying to find consensus about which program is to
>   be renamed, is that consensus among the maintainers of the packages
>   involved or some other group?  In other words, is stonewalling an
>   acceptable and viable strategy?

The consensus is among the Debian contributors group and not
restricted to the involved package maintainers.

> - Policy says that in the absence of consensus, both packages must be
>   renamed.  A number of people have mentioned that that looks like a
>   bad outcome from the users' perspective.

When there is a real risk of confusion, renaming both packages avoid any
user confusion, so this is sometimes the best outcome.

>   Policy also states that different packages must not install commands
>   with different functionality with the same name.

Such packages would have to Conflicts anyway, and gratuituous conflict
must be avoided. This is not a waivable requiremrent.

>   If a consensus develops around a solution that does not follow
>   policy, could it be implemented?  There is something of a precedent
>   for this kind of question in the transition plan for the
>   gnuit/git-core command name conflict. 

>   This was before my time, but
>   if I understand correctly then update-alternatives was used for one
>   release to multiplex between the actual commands and a wrapper
>   script that used command line arguments to figure out which command
>   was meant.  Ugly as sin (and not a good technical example here), but
>   it happened because the maintainers of those packages and the
>   release team agreed it was the best we could do.

GNU Interactive Tools was in Debian since several releases before Linus GIT was
introduced. While the consensus was that git should point to Linus GIT instead
of GNU IT eventually, care were taken to provide an upgrade path to GNU IT users
with minimal breakage, and this was completed in several releases.

Cheers,
-- 
Bill. <ballombe at debian.org>

Imagine a large red swirl here.