How to resolve a technical conflict

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to resolve a technical conflict

Perry E. Metzger-2
So an instance of something that hasn't happened much has appeared,
and I'd like some guidance both on the individual instance and on the
problem in general.

Our gpg2 port currently depends on building the entirety of the
openldap infrastructure. gpg2 optionally can use openldap for
retrieving keys, but _*almost no one does this*_. It strikes me as
unpleasant and wasteful to have a substantial dependency that
almost no one uses or cares about; at least a variant that doesn't
require openldap would seem to be in order. However, the port
maintainer doesn't want to have a variant that doesn't depend on
openldap. He thinks things are fine as they are.

1. How does one adjudicate this particular dispute?
2. How does one adjudicate such disagreements in general?

At the moment, our process gives a port maintainer absolute say over
how a port is maintained, but I don't think that's always reasonable.
However, we have no mechanism for settling a disagreement.

Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to resolve a technical conflict

Rainer Müller-4
On 03.11.18 14:27, Perry E. Metzger wrote:
> So an instance of something that hasn't happened much has appeared,
> and I'd like some guidance both on the individual instance and on the
> problem in general.

[...]

> 1. How does one adjudicate this particular dispute?
> 2. How does one adjudicate such disagreements in general?
>
> At the moment, our process gives a port maintainer absolute say over
> how a port is maintained, but I don't think that's always reasonable.
> However, we have no mechanism for settling a disagreement.

As far as I am aware, we were always able to find a solution that works
for both the maintainer and other developers requesting changes.

I would appreciate if we could try to find a compromise here as well.
As long as the variant is enabled by default, the contents and
functionality of the port will not change. Such a variant should also
not require much, if any, maintenance effort.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: How to resolve a technical conflict

Perry E. Metzger-2
On Sat, 3 Nov 2018 15:44:58 +0100 Rainer Müller <[hidden email]>
wrote:
> I would appreciate if we could try to find a compromise here as
> well. As long as the variant is enabled by default, the contents and
> functionality of the port will not change. Such a variant should
> also not require much, if any, maintenance effort.

That was what the original pull request suggested, but the maintainer
has rejected it. :(

That said, it seems like a reasonable compromise to me.

Perry
--
Perry E. Metzger [hidden email]