From owner-freebsd-ports@freebsd.org Sat Sep 17 03:09:08 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBF62BDD846 for ; Sat, 17 Sep 2016 03:09:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B9B1CA1F for ; Sat, 17 Sep 2016 03:09:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B9174BDD844; Sat, 17 Sep 2016 03:09:08 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8BA4BDD843 for ; Sat, 17 Sep 2016 03:09:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 712FDA1E for ; Sat, 17 Sep 2016 03:09:08 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id 192so53353541vkl.0 for ; Fri, 16 Sep 2016 20:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XBB74+pKas5IOIyXwF0tP9QV+DIxswH6XuFv8JTKjfI=; b=Yqz19fAC82FoR/UECvaIeB2JRlJwbxYeBYj+V3WyJKA/TbIVc6dSF27NtXgAMTQvc9 8DS7YcX743t+lMMzP5pF/GmawyHxKy+BDSdP9UWPd39Q6/v0d3xhD5TjCdp6mhmhInMF Zj7dB/x2FXxE+o79ynHyRkm1Oc6Tc8yXYnU10Xfv5Jb/i7X6j6MmJ5n8/pAhiR/8qvK/ KTpbEEANjkDkD4XMtbglnaCIeth2gIMcTjf9ip77DInrUwLSbFLgYhj8M56YxnXKsSjL F3af5Ul2if63s54SW7ln4FoqTEIrybUJKtCSwQJwSn3QRc+XnyzP3C7tL4VPv03SkVUy b0Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XBB74+pKas5IOIyXwF0tP9QV+DIxswH6XuFv8JTKjfI=; b=Gno/2G3eW4iEacqC5hzbkm8l7UgJ/WmRrL6Qmm8tTcJNCBUV8c09KOUFQKrVukx18O VDt7316mxLWVOCkgPoI/wX5TtnUkhspw9Qnrl4tNOmkcNDB4uU20zk/bZsYhlwhP3m04 aZOfpxkoYef6G7d1H0F3eGLnaEx89/mnqBBo2zswUCJ9nSDyCn1dsXtlP+fo+UQh4iWA be0BjV4alIZH0GN2B949e4HV2M+RWxnuWQUR5Q5+Bh8EIkifmSiH6VFSXkLsJdpuK+W0 49JYUVoWdP8FkgUCPBZfQoLdPbDO62h3qtCQcR1DEWDJLmuYx/nGmnYLLDVPLv2dq5S5 zqpg== X-Gm-Message-State: AE9vXwOsdcg4UK7iUCL5nilvctnaJ6kznJiPoQUHKMQBIrnxH/gcDwaY/vs0c03kk8lk5vGecVfrtDG1VZh+cQ== X-Received: by 10.31.207.198 with SMTP id f189mr6932800vkg.56.1474081747532; Fri, 16 Sep 2016 20:09:07 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.35.200 with HTTP; Fri, 16 Sep 2016 20:09:06 -0700 (PDT) In-Reply-To: References: <3de26d31-e4e0-ddc4-27ae-03bab473849b@ohlste.in> From: Kevin Oberman Date: Fri, 16 Sep 2016 20:09:06 -0700 X-Google-Sender-Auth: Q4KCxcztcXT2LBlJKaHee6JcAkI Message-ID: Subject: Re: Checking port option descriptions To: scratch65535@att.net Cc: freebsd-ports Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2016 03:09:09 -0000 On Fri, Sep 16, 2016 at 3:42 PM, wrote: > On Fri, 16 Sep 2016 15:11:51 -0400, Jim Ohlstein > 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@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683