On Monday, June 05, 2017 02:42:37 PM Ian Jackson wrote:
> Jeremy Bicha writes ("Re: Too many Recommends (in particular on mail-
transport-agent)"):
> > On Mon, Jun 5, 2017 at 9:15 AM, Ian Jackson
> >
> > <ijackson@chiark.greenend.org.uk> wrote:
> > > It does seem that some maintainers are unclear on these principles, or
> > > their application; despite what seems to me to be very clear wording
> > > in policy. So I think we need some examples. To work well they
> > > should have a high profile and be authoritative, so that means taking
> > > a couple of contested cases to the TC. Maybe #849619 would make a
> > > good test case.
> >
> > Respectfully, #849619 is not at all a very convincing test case yet.
>
> That's why I wrote, earlier:
> > Before doing that, it would be wise to try to find the answer to the
> > key question which the TC will ask. Suppose A recommends B. In what
> > way, or in what circumstances, will A fail due to lack of B ?
> >
> > In #849619 I don't see the answer to that question.
>
> The answer to that is not clear from the maintainer's response; nor is
> it clear from what the submitter has written whether they know the
> answer.
Why is that question relevant? The policy definition of Recommends (versus
Suggests) has nothing to with if there will be a failure or not:
> The Recommends field should list packages that would be found together with
> this one in all but unusual installations
Personally, I think the maintainer articulated what he views as the usual
situation and declines to remove Recommends that are, in the maintainer's
view, appropriate. His rationale makes complete sense to me. I'm not saying
there aren't other, reasonable choices that could be made, but it make sense.
I don't think this is the kind of thing the TC should even entertain
overruling a maintainer on.
For things like this, get consensus on a new definition for Recommends first
as this looks to me to be well within the scope of the current definition.
Not even close.
Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.