Checking port option descriptions

[Kevin Oberman]

On Fri, Sep 16, 2016 at 3:42 PM, <scratch65535 at att.net> wrote:

> On Fri, 16 Sep 2016 15:11:51 -0400, Jim Ohlstein <jim at ohlste.in>
> wrote:
>
> >"[S]ome" being the operative word here. I don't disagres with your basic
> >premise, but the truth is, at the end of the day it's up to the user to
> >understand the consequences of his decisions. If a user doesn't know
> >what 'XYZ' is, then adding 'Include protocols for use with XYZ servers'
> >probably doesn't tell him or her that much. On the other hand, if a user
> >knows what 'XYZ' is, then 'Enable XYZ' is likely enough information with
> >which to make a decision.
> >
> >So in this case there are likely to be two categories of users: those
> >who know what 'XYZ' is and those who do not. Those in the former have
> >the information either way. Those in the latter have three basic choices:
> >
> >1) Educate themselves before possibly adding software to their system
> >that they do not fully understand, thereby moving into to the former
> >category.
> >
> >2) Choose the default, on the (very possibly mistaken) assumption that
> >the porter "knows what's best." Unfortunately that assumption may be a
> >bad one, as the porter/maintainer is more likely to choose something
> >that satisfies "most users" and loads people with unnecessary
> >dependencies (thus defeating much of the benefit of building your own
> >ports), or worse, to choose options that work best for him or her.
>
> Most people want to *use* the machine they're integrating.  For
> them it's not a pastime or hobby.
>
> Very few such people have the time or energy to "educate
> themselves" enough to understand the interactive effects of the
> many MANY options for each of the ports they want to install.
>
> In part, that's due to the useless "comments" Warren rightly
> calls out in his post.  So yes, in hope of being safe, they'll
> accept the defaults.  With real, thoughtful, information-rich
> comments, that might actually happen less often.
>
> The same problem affects software development and causes a lot of
> code to be re-written from scratch rather than maintained.  Told
> to comment their code, too many programmers write things like "
> x=x+1 ; // increment x" and are baffled when more experienced
> engineers are scathing during code review.  After all, they did
> comment each line, so what's the problem?  If people want to
> understand what the code does, they should study it!
>

While I agree that you can't hope to fully cover the meaning of the each
option, some clue as to what it means if just so we can know where to look
for more information. Some items are both hard to describe briefly and not
worth the effort. E.g. the long list of available codecs and formats. What
can you hope to say about inclusion of speex or x264 in the available
space? On the other hand, what the heck is VDPAU? (Yes, I know, but lots of
people don't). Also, if an option has licensing implications, that's
important to many, but seldom mentioned.

Even when the meaning is clear in  global sense, what are the implications
for an application. E.g. "RTC=on: Add support for kernel real time clock"
in mplayer. I know exactly what the RTC is, but I have no idea why I might
or might not want it in mplayer.

No, I don't know the best thing in many cases, but I can assure you that
the defaults, while usually a good choice, are sometimes not. A prime
example is optimization. It is almost always desirable, but is usually not
default so that the package can be run on any hardware.

I have no answers, but it's not easy or clear-cut, but there is clearly
room for improvement.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683