Gentoo Archives: gentoo-project

From: Roy Bamford <neddyseagoon@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13
Date: Mon, 05 Dec 2011 19:01:38
Message-Id: 1323111658.2771.0@NeddySeagoon
In Reply to: Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13 by Rich Freeman
1 On 2011.12.05 13:25, Rich Freeman wrote:
2 > 2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh@g.o>:
3 > > Among the people preferring to see build output, making -v control
4 > the
5 > > default seems to be considered an acceptable compromise. So
6 > wouldn't
7 > > that be great? Hiding build output by default, while still
8 > satisfying
9 > > most critics of this idea.
10 >
11 > I don't care that strongly about the defaults since I can change them
12 > (though I'd like them to be reasonably sane so that people take us
13 > seriously).
14 >
15 > However, making -v control the output seems like a problem, unless
16 > there is some way to undo this. A typical workflow for me is to run
17 > emerge -auDNv world to see what is going to build, and then hitting
18 > enter to accept it. I want to get the verbose USE info with -a/p,
19 > but
20 > I don't really care to see build logs flying across the screen. So,
21 > overloading a single flag to do both sounds problematic unless you
22 > also allow the quiet flag to override it back. That seems
23 > complicated
24 > to me.
25 >
26 > That raises another portage flags issue - the fact that we need so
27 > many options to do "the right thing." Now, I'll argue the right
28 > thing
29 > is subjective so we do need to be able to control it. However, it
30 > seems like we should be able to agree on the best setting for
31 > general-purpose updates is, and make that a single setting.
32 >
33 > As far as opinions vs facts go - in software design the only real
34 > facts are whether a particular design satisfies or does not satisfy a
35 > particular requirements specification, or dry measures like
36 > benchmarks/scalability/etc. Whether a particular design is "better"
37 > is always a matter of opinion, unless better simply means satisfying
38 > more requirements or some other objective measure. That then just
39 > begets the question as to whether one set of requirements is better
40 > than another, and that is just vodoo. Actually, even stating as a
41 > "fact" whether a program even meets a requirement is extraordinarily
42 > difficult for all but the most trivial programs - you can't even
43 > prove
44 > conclusively whether the program will always terminate short of
45 > exhaustively testing all possible input.
46 >
47 > That's why we could perpetuate this thread for six months and never
48 > really resolve the issue, and ultimately sometimes you just need a
49 > council to weigh in with their opinion, when everybody can't live
50 > with
51 > the maintainer's opinion.
52 >
53 > Rich
54 >
55 >
56
57 Rich,
58
59 I'll stir the pot a little. I'm only replying here as I want to bring
60 out a few facts.
61
62 1. When portage was created, almost all of us used to build on single
63 CPU/core machines.
64
65 2. Builds would progress at a speed where the portage output could be
66 read as the build progressed.
67
68 3. A few sad individuals (including me) could read the portage output
69 and know where a build was.
70
71 4. The number of parallel makes was low enough for any errors to still
72 be in the back buffer.
73
74 5. CPUs have grown faster over the years, so the build output has
75 scrolled by faster.
76
77
78 Opinion.
79 a) With my current system, postage output scrolls too fast for me to
80 read.
81
82 b) Portage on screen output is now useless to me, since I have to look
83 in the build log for errors anyway.
84
85 c) This default is well overdue a change to keep up with the times.
86
87 Do we want Gentoo to be first into the future and last out of the past?
88
89 --
90 Regards,
91
92 Roy Bamford
93 (Neddyseagoon) a member of
94 elections
95 gentoo-ops
96 forum-mods
97 trustees