From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-59946-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 8F49B1381F3
for <garchives@archives.gentoo.org>; Tue, 30 Apr 2013 12:40:55 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E5B55E095B;
Tue, 30 Apr 2013 12:40:51 +0000 (UTC)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 046C3E0942
for <gentoo-dev@lists.gentoo.org>; Tue, 30 Apr 2013 12:40:50 +0000 (UTC)
Received: by mail-vb0-f54.google.com with SMTP id w16so347086vbf.13
for <gentoo-dev@lists.gentoo.org>; Tue, 30 Apr 2013 05:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=8im3S5wbvyOK2yHLS2JpN1ZNC34KObG980UyHC+yxRM=;
b=pX83BG2hQWL7epQhwPkf+e3MRW5/oqCYnUtIXxixtUSjhIPq1Jo8XqNMtjGs08q4lI
sSB+YeOV5qNqW75q+IscWlYoN/qfFz2ZRMSd04ri7hXe05ajO76A8QhKpRkZWrhS1A6e
zr89vGFpk4PSQ8jdsvf8rt9CRGtEK5T9uKlx3m9qnMV/NnCKXXJvDg88w4Q0lKlb9tAJ
VZh1wFv5oASkMBRhwP765JO+ro3Px8UbQ5oceRZKUve0ASodX0JEue+7OIVQ7/Su1Qvn
IzLxZtTLF1t5/rKHvoXXXbo+4zqsDbDgS58f/waIgbg+yEeqxJDqjE5p3XwCfKvALp/o
EzyQ==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.58.29.101 with SMTP id j5mr5377251veh.26.1367325650152; Tue,
30 Apr 2013 05:40:50 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.168.4 with HTTP; Tue, 30 Apr 2013 05:40:50 -0700 (PDT)
In-Reply-To: <pan$a72e6$955a0431$f78513ef$ffa10d25@cox.net>
References: <20130429075549.06e8ad66@gentoo.org>
<201304291436.42577.vapier@gentoo.org>
<20130429194917.46d4985c@googlemail.com>
<20862.56778.599974.921136@a1i15.kph.uni-mainz.de>
<20130429215950.019cd23b@googlemail.com>
<20862.62111.902255.208565@a1i15.kph.uni-mainz.de>
<20130429232709.6d755604@googlemail.com>
<CAGfcS_=ACKnXDOxbQKm1bJRdtf_7v4u2+L1CDJPKUGY3JHK31A@mail.gmail.com>
<pan$616a5$bb9fd5da$9bb940$fb08155@cox.net>
<20130430121213.330244bc@googlemail.com>
<pan$a72e6$955a0431$f78513ef$ffa10d25@cox.net>
Date: Tue, 30 Apr 2013 08:40:50 -0400
X-Google-Sender-Auth: SjVr8rDRhf7AnW6uxQEiUfapeNM
Message-ID: <CAGfcS_mdxMoMsVDMmzP261H1yE54U7LEga_RFdmLvstDOoCAiQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of
./configure invocation?
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 2bef8b9f-80b1-4a96-8328-97651936c063
X-Archives-Hash: c9a3200a7cf76bf876bef6e0c5f626c4
On Tue, Apr 30, 2013 at 8:30 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Another analogy would be that these people are human versions of the
> kernel's trinity fuzz tester...
Requirements generally are not intended to be defensible to fuzz
testing, or completely determinate. Rather, they're intended to be
detailed in the things that are really critical, and less detailed
where everybody should be able to get the gist of what is specified.
When you actually take the time to write an absolutely unambiguous
requirement spec a few things happen:
1. Nobody bothers to read it.
2. Those who read it can't grok it, because the forest is invisible
for the trees.
3. The result of 1+2 is that the spec usually ends up being wrong.
So, if the goal of the exercise is to be able to blame the people who
signed the requirement for anything that goes wrong, then an extremely
detailed requirements document is generally the best way to go. If
the goal is to just get everybody on the same page and align subject
matter experts with those who will be designing/coding the software,
then the appropriate level of details is generally lower.
There are also compromises like a series of nested documents that
spell out the specs in increasing levels of detail (use cases,
business requirements, functional requirements, design specifications,
etc). This a fairly bureaucratic exercise, and rarely do orgs have
the time to properly document and maintain trace-ability between
these, so the result is that it ends up being a lot of paper done for
the sake of checking boxes and the code is even more likely to be
broken because everybody is looking at different documents that are
never completely in-sync. However, done right (ie, with cost overruns
like that of the F-35) this can allow projects to scale to fairly
large sizes.
Most of us are here because we find it "fun," so I think the simplest
solution is to just do the right thing and treat requirements docs as
useful tools when they're actually useful. I think PMS has been a
great thing for Gentoo, but we shouldn't treat changing it like
changing the TCP spec.
Rich