1 |
On Thu, Oct 05, 2017 at 04:18:42PM -0700, Rich Freeman wrote: |
2 |
> (Apologies in advance if it seems like I'm picking on you. I want to |
3 |
> make a point more than criticize you in particular, because I'm sure |
4 |
> your motivation is care and not impediment.) |
5 |
|
6 |
No worries. I appreciate the time spent to converse about it. |
7 |
|
8 |
> |
9 |
> On Thu, Oct 5, 2017 at 3:54 PM, Daniel Campbell <zlg@g.o> wrote: |
10 |
> > |
11 |
> > I don't arch test because (a) I don't use stable and (b) I don't want to |
12 |
> > mess something up. |
13 |
> |
14 |
> And if everybody else does this then nobody will use stable, because |
15 |
> it will be messed up. :) |
16 |
> |
17 |
> > There are also too many ways to do arch testing and |
18 |
> > it's not clear which method is most reliable. |
19 |
> |
20 |
> The problem is that we need people do do some testing. If nobody |
21 |
> tests anything because nobody has found the "most reliable" way to |
22 |
> test things, then everybody will end up using completely untested |
23 |
> software by default. |
24 |
> |
25 |
> IMO this is one of those situations where the perfect is the enemy of the good. |
26 |
> |
27 |
> > chroots can be problematic |
28 |
> > since they have bound mounts to the host system and the interaction |
29 |
> > between systems can present false positives for issues, and are fragile |
30 |
> > to maintain. A VM comes with its own set of problems (drivers, I/O, |
31 |
> > admin overhead), and containers are a world all their own. |
32 |
> > |
33 |
> |
34 |
> Obviously testing grub in a chroot isn't going to work. However, |
35 |
> unless you're doing testing of drivers/kernel/bootloader/etc a chroot |
36 |
> will be fine for just about anything. A container would be even |
37 |
> better, and the difference between a container and a chroot is about 2 |
38 |
> shell commands. |
39 |
> |
40 |
> > Perhaps arch testing would be more attractive if there was One True Way™ |
41 |
> > to setup an arch testing system |
42 |
> |
43 |
> I think arch testing would be more effective if people stopped |
44 |
> worrying about the One True Way and just did some arch testing, any |
45 |
> way they can. Just about every stable keyword in the tree is the |
46 |
> result of this, and this is how it has always been on Gentoo. |
47 |
> |
48 |
> The moment I post a suggested One True Way somebody is going to point |
49 |
> out one bug in the last 10 years that would have escaped detection, |
50 |
> and suggest that nothing should be keyworded until a rigorous 300 step |
51 |
> process has been run, featuring tinderboxes that nobody is bothering |
52 |
> to build, and automated tests that nobody is going to write. Then |
53 |
> we'll bikeshed for six months about the pros and cons of 14 different |
54 |
> methods of tinderbox log analysis, and people will start wondering why |
55 |
> the subject line says something about stable keywords. :) |
56 |
> |
57 |
> > and higher level tools to facilitate bug |
58 |
> > interaction. |
59 |
> |
60 |
> That would certainly be lovely, but it requires somebody to build |
61 |
> those tools, and I don't see that as a short term solution. |
62 |
> |
63 |
> I think that encouraging devs to be a little less afraid of mistakes |
64 |
> is probably the right way to go. There is a balance between paralysis |
65 |
> and running around just keywording everything in sight without even |
66 |
> bothering to build it. If you get feedback that something broke just |
67 |
> do things a little differently next time. The fact that some dev got |
68 |
> yelled at by QA because he ran some shell script that wrought havoc |
69 |
> upon the tree 6 years ago isn't a reason why everybody should be |
70 |
> afraid to make a good-faith effort. |
71 |
> |
72 |
> If the Council wants proposals for a resolution to define for once and |
73 |
> all what "stable" means I can toss something out there. Short of that |
74 |
> I suggest that the people actually bothering to keyword stuff are |
75 |
> going to get to write the rules... |
76 |
> |
77 |
> -- |
78 |
> Rich |
79 |
> |
80 |
|
81 |
Solid points, some I hadn't thought of. If I get the spare time, I'll |
82 |
consider setting up a chroot, even if its only for stabilizing packages |
83 |
I'm familiar with. In the aggregate, it could reduce testing burden over |
84 |
the long term. |
85 |
|
86 |
Thanks for giving me a reason to reconsider. |