Bug#671120: debian-policy: suggest delegating binary name conflicts to tech-ctte in last resort

[Carsten Hey <carsten@debian.org>]

Hi,

in 2012 there was a consensus, and this bug was filed.
In 2014 there was a single mail w/o reply (possibly because this bug
        needed a patch, not yet another discussion), but no consensus.
In 2016 this bug was closed under wrong assumptions.
In 2018 or later this bug might be filed again, hopefully with a patch.

* Bill Allombert [2014-03-23 16:56 +0100]:
> On Wed, May 02, 2012 at 12:13:22AM +0200, Carsten Hey wrote:
> > Package: debian-policy
> > Severity: wishlist
> >
> > Please suggest delegating binary name conflicts to the tech-ctte in last
> > resort.
>
> Anything can be delegated to the tech-ctte. I do not think policy need to
> mention it.

Different wording for "we do not force both binary names to be changed"
are welcome^W^Wwill be welcome.

> > * Russ Allbery [2012-05-01 10:28 -0700]:
> > > Carsten Hey <carsten@debian.org> writes:
> > >
> > > > The origin of what the policy suggests to do if there is no consensus is
> > > > a mail from Guy Maor <879142cjni.fsf@slip-61-16.ots.utexas.edu>, in
> > > > which he writes:
> > > > | That's basically a stick to force developers to reach a consensus.
> > >
> > > > Christian Schwarz uploaded this change later in this month.
> > >
> > > > I don't think that there ever will be a consensus in all those
> > > > discussions without discussing in a reasonable way (which failed in the
> > > > past multiple times).  Previously to this, asking the VP of Engineering
> > > > for a decision was suggested in this thread.
> > >
> > > I have to admit that I'm tempted to change Policy from "if there's no
> > > consensus, rename both of them" to "if there's no consensus, try harder to
> > > reach a consensus, and the technical committee decides in last resort."
> >
> > "technical committee decides in last resort" could be read as if it
> > would decide without being consulted.  To avid such a misreading,
> > a clearer wording that for example uses the word 'consulted' could be
> > used.
> >
> > Besides this minor nitpicking, it would be great if the policy could be
> > adapted as described in the quoted mail.
> >
> > > Most of the time, renaming both of them isn't the right answer.
> >
> > I'm even unable to imagine a case where renaming both would be the right
> > answer.
>
> Whenever the unqualified name become ambiguous.

This is not the original intention of this paragraph (which not
necessarily means that it's not reasonable or valid).

There are consensual transitions of binary names between packages, and
there are conflicting binary names without any consensus among the
maintainers - Russ and I talked about the latter, and Bill's mail reads
as if he had both cases in mind.

> If a package name is used in one release, it cannot change purpose in the next
> release, there needs some transition period.

That's very often, possibly almost always, a sane way to handle such
transitions.  I wonder if node was handled this way four years ago.
Anyway, I can imagine cases where it's reasonable to have no transition
period, and more importantly, dictating higher level designs by
specifying low level implementation details in the policy not only feels
wrong - especially if these higher level design issues aren't mentioned
in the policy at all.

> An example is git transition: Since git was already used as a package name,
> both GNU IT and Linus git were renamed for one release.


Regards
Carsten