Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
Date: Tue, 30 Apr 2013 12:40:55
In Reply to: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation? by Duncan <>
1 On Tue, Apr 30, 2013 at 8:30 AM, Duncan <1i5t5.duncan@×××.net> wrote:
2 > Another analogy would be that these people are human versions of the
3 > kernel's trinity fuzz tester...
5 Requirements generally are not intended to be defensible to fuzz
6 testing, or completely determinate. Rather, they're intended to be
7 detailed in the things that are really critical, and less detailed
8 where everybody should be able to get the gist of what is specified.
10 When you actually take the time to write an absolutely unambiguous
11 requirement spec a few things happen:
12 1. Nobody bothers to read it.
13 2. Those who read it can't grok it, because the forest is invisible
14 for the trees.
15 3. The result of 1+2 is that the spec usually ends up being wrong.
17 So, if the goal of the exercise is to be able to blame the people who
18 signed the requirement for anything that goes wrong, then an extremely
19 detailed requirements document is generally the best way to go. If
20 the goal is to just get everybody on the same page and align subject
21 matter experts with those who will be designing/coding the software,
22 then the appropriate level of details is generally lower.
24 There are also compromises like a series of nested documents that
25 spell out the specs in increasing levels of detail (use cases,
26 business requirements, functional requirements, design specifications,
27 etc). This a fairly bureaucratic exercise, and rarely do orgs have
28 the time to properly document and maintain trace-ability between
29 these, so the result is that it ends up being a lot of paper done for
30 the sake of checking boxes and the code is even more likely to be
31 broken because everybody is looking at different documents that are
32 never completely in-sync. However, done right (ie, with cost overruns
33 like that of the F-35) this can allow projects to scale to fairly
34 large sizes.
36 Most of us are here because we find it "fun," so I think the simplest
37 solution is to just do the right thing and treat requirements docs as
38 useful tools when they're actually useful. I think PMS has been a
39 great thing for Gentoo, but we shouldn't treat changing it like
40 changing the TCP spec.
42 Rich