1 |
On Fri, 24 Jan 2014 12:10:30 -0600 |
2 |
Steev Klimaszewski <steev@g.o> wrote: |
3 |
|
4 |
> The problem isn't finding someone that has everything - we have people |
5 |
> that test on ARMv5, some that test on ARMv6, we have some that test on |
6 |
> ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. |
7 |
> So again, it just shuffles around the work, and does nothing to |
8 |
> address the actual problem which is manpower with people that have |
9 |
> the slower machines to finish their testing. Unless you would like |
10 |
> to suggest that we maybe just say fuck anyone using a slow machine? |
11 |
|
12 |
Consider how packages would rarely get stabilized if we had to wait for |
13 |
all arches to test them first before adding any stable keyword at all. |
14 |
|
15 |
Organize first, then get more manpower; otherwise we say the F-word to |
16 |
everyone with a faster machine. Joining arm with a slower configuration |
17 |
and have everyone waiting on you is a working condition to avoid; so, |
18 |
we could have the slower configuration stabilize at its own pace. |
19 |
|
20 |
Would we say F-word to 'em? No, we give them better working conditions. |
21 |
|
22 |
> I disagree, and think we should take care of all of our users, not |
23 |
> just the bleeding edge and fast users. |
24 |
|
25 |
Theoretically, yes, everyone wants that; in practice, manpower as well |
26 |
as performance is limited, which makes "taking care of all" a rather |
27 |
hard to aim goal. |
28 |
|
29 |
We still aim to satisfy everyone; I look at discussions from multiple |
30 |
sides to see how we can satisfy as much people as possible, hence |
31 |
providing multiple solutions. It however is rare that a solution works |
32 |
for everyone, there are too much requirements for that to be possible. |
33 |
|
34 |
But, making it hold up other people's work is a recipe for problems, to |
35 |
which point someone comes up with a forced stabilization as you gave as |
36 |
an example. In other words, minor configurations shouldn't stall things |
37 |
forever; just like minor arches shouldn't stall things forever, which |
38 |
would have been a huge problem if we would only allow stable keywords |
39 |
to be added when all the arch teams have tested it. |
40 |
|
41 |
> > > Getting them into the arch team and willing to run stable and |
42 |
> > > actually test programs is a whole other story, which lead to you |
43 |
> > > saying: |
44 |
> > > |
45 |
> > > "People that have certain architectures can just add themselves, |
46 |
> > > no extra work again." |
47 |
> > |
48 |
> > Which is for people already on the arm arch; consider the context |
49 |
> > you quote this from, rather than assuming what is not explicitly |
50 |
> > stated. |
51 |
> > |
52 |
> |
53 |
> That doesn't make any sense - if they are already on the arm arch |
54 |
> team, they are already in the list. |
55 |
|
56 |
Being on the arm arch team alias, they can add themselves to the |
57 |
individual configuration teams aliases; as per the context. |
58 |
|
59 |
> That wasn't the context of the quote AT ALL. |
60 |
|
61 |
It was: |
62 |
|
63 |
@TomWij | Why would it result in more emails? When you are part of |
64 |
multiple aliases you can have it filter down to one; or otherwise, you |
65 |
can just sort them down to folders and only keep the revelant ones. |
66 |
@steev | so we should have armvX aliases? |
67 |
@steev | what if you want package X to be stable on only armv5 and |
68 |
armv7 |
69 |
@TomWij | Yes, then you just CC those. |
70 |
@steev | and those go to the arm alias, or we have to create armvX |
71 |
aliases, and add people to that - again, more work for me, less work |
72 |
for you - nothx |
73 |
@TomWij | steev: People that have certain architectures can just add |
74 |
themselves, no extra work again. |
75 |
|
76 |
> And I told you when you |
77 |
> said that it would allow people to add or remove themselves willy |
78 |
> nilly, and that is NOT going to happen - and would NOT be good for QA. |
79 |
|
80 |
You keep bringing up this assumption; it has been made clear multiple |
81 |
times that so far, like for instance right after you have made it: |
82 |
|
83 |
@steev | no. |
84 |
@steev | the point of the arch team isn't so people can randomly pop |
85 |
in, add themselves, do something, then leave the team willy nilly |
86 |
@TomWij | Indeed, as I said half an hour ago. |
87 |
|
88 |
Note that this comes right after the previous quote of the context. |
89 |
|
90 |
And that reference to half an hour ago points to this: |
91 |
|
92 |
@steev | TomWij: because people are breaking stable, and if |
93 |
someone isn't happy with the arch team's speed, they should join the |
94 |
arch team to help out, and realize just how much work it ACTUALLY is |
95 |
@steev | should we allow anyone with an android phone to stable for |
96 |
arm because they can throw a gentoo chroot onto their phone? |
97 |
@TomWij | Under the condition proper arch testing is done, thus |
98 |
according to arm's arch policies; that should be fine to do yes. If you |
99 |
need it tested on multiple configurations, then I guess the person |
100 |
could use multiple phones. |
101 |
|
102 |
> > > What you've thrown out as a possible solution is akin to taking a |
103 |
> > > pile of peas on the plate and moving them around the plate so |
104 |
> > > that the pile doesn't look so big. |
105 |
> > |
106 |
> > In other words, using separation to organize them properly. |
107 |
> > |
108 |
> > > It doesn't change the amount of work, but you do need to look in |
109 |
> > > more places for the work. |
110 |
> > |
111 |
> > Which you can collect back into one place. |
112 |
> > |
113 |
> > > Finding people with the hardware is the main issue, and I think I |
114 |
> > > mentioned before, some people are simply unwilling to invest in |
115 |
> > > "slow" hardware, so we have to rely on the people who DO have it. |
116 |
> > > And if that means things take longer to stable, well, why is that |
117 |
> > > an issue? Stable is supposed to be that - stable. |
118 |
> > |
119 |
> > That is because you only look for people that have all the hardware. |
120 |
> > |
121 |
> |
122 |
> No, we do not look ONLY for people that have all the hardware. But |
123 |
> until it's tested on all of the arm arches, it doesn't get stabled. So |
124 |
> your suggestion is "split it out to blah blah blah blah" - so that |
125 |
> moves it around - but you know what? the slower machines are STILL |
126 |
> going to take forever (because they are slow!) and the ebuilds will |
127 |
> still need to stick around, because we will still be waiting. |
128 |
> Problem NOT solved, problem just moved around a tiny bit. |
129 |
|
130 |
Your configurations problem would be solved, which is a good start; |
131 |
so, let us fix actually fix it, instead of covering it up and waiting. |
132 |
|
133 |
> > > So, as QA, shouldn't you be doing something about that, rather |
134 |
> > > than pointing to some URLs on the web, telling me I'm in the |
135 |
> > > wrong for using the option that is supposed to handle that |
136 |
> > > properly in my stable software? |
137 |
> > |
138 |
> > The problem lies in a different place than the software itself. |
139 |
> > |
140 |
> |
141 |
> Spoken like a true QA person. Glad this is the type of person we have |
142 |
> on our QA team. |
143 |
> |
144 |
> This is why everyone makes fun of our QA team, because we allow people |
145 |
> in who don't actually give a shit about QA, only about covering up |
146 |
> issues so they appear good but don't actually fix shit. |
147 |
|
148 |
Can we talk about the matter instead of about the person? |
149 |
|
150 |
So, how to fix a problem in software when it is not in the software? |
151 |
|
152 |
PS: Note that I have been devaway for almost two weeks. |
153 |
|
154 |
-- |
155 |
With kind regards, |
156 |
|
157 |
Tom Wijsman (TomWij) |
158 |
Gentoo Developer |
159 |
|
160 |
E-mail address : TomWij@g.o |
161 |
GPG Public Key : 6D34E57D |
162 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |