Gentoo Archives: gentoo-dev

From: Steev Klimaszewski <steev@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Fri, 24 Jan 2014 18:10:41
In Reply to: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Tom Wijsman
1 On Fri, 2014-01-24 at 18:26 +0100, Tom Wijsman wrote:
2 > On Thu, 23 Jan 2014 21:52:47 -0600
3 > Steev Klimaszewski <steev@g.o> wrote:
4 >
5 > > The idea moves the work around, it doesn't lessen the workload at all.
6 >
7 > It is an idea to solve your actual problem, which isn't workload.
8 > > You can easily find 7 people who have an armv7, and even v6, since the
9 > > rpi is quite popular.
10 >
11 > They are easier to find than someone that has everything.
12 >
14 The problem isn't finding someone that has everything - we have people
15 that test on ARMv5, some that test on ARMv6, we have some that test on
16 ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. So
17 again, it just shuffles around the work, and does nothing to address the
18 actual problem which is manpower with people that have the slower
19 machines to finish their testing. Unless you would like to suggest that
20 we maybe just say fuck anyone using a slow machine? I disagree, and
21 think we should take care of all of our users, not just the bleeding
22 edge and fast users.
25 > > Getting them into the arch team and willing to run stable and
26 > > actually test programs is a whole other story, which lead to you
27 > > saying:
28 > >
29 > > "People that have certain architectures can just add themselves, no
30 > > extra work again."
31 >
32 > Which is for people already on the arm arch; consider the context you
33 > quote this from, rather than assuming what is not explicitly stated.
34 >
36 That doesn't make any sense - if they are already on the arm arch team,
37 they are already in the list. That wasn't the context of the quote AT
38 ALL. And I told you when you said that it would allow people to add or
39 remove themselves willy nilly, and that is NOT going to happen - and
40 would NOT be good for QA.
42 > > What you've thrown out as a possible solution is akin to taking a pile
43 > > of peas on the plate and moving them around the plate so that the pile
44 > > doesn't look so big.
45 >
46 > In other words, using separation to organize them properly.
47 >
48 > > It doesn't change the amount of work, but you do need to look in more
49 > > places for the work.
50 >
51 > Which you can collect back into one place.
52 >
53 > > Finding people with the hardware is the main issue, and I think I
54 > > mentioned before, some people are simply unwilling to invest in
55 > > "slow" hardware, so we have to rely on the people who DO have it.
56 > > And if that means things take longer to stable, well, why is that an
57 > > issue? Stable is supposed to be that - stable.
58 >
59 > That is because you only look for people that have all the hardware.
60 >
62 No, we do not look ONLY for people that have all the hardware. But
63 until it's tested on all of the arm arches, it doesn't get stabled. So
64 your suggestion is "split it out to blah blah blah blah" - so that moves
65 it around - but you know what? the slower machines are STILL going to
66 take forever (because they are slow!) and the ebuilds will still need to
67 stick around, because we will still be waiting. Problem NOT solved,
68 problem just moved around a tiny bit.
70 > > So, as QA, shouldn't you be doing something about that, rather than
71 > > pointing to some URLs on the web, telling me I'm in the wrong for
72 > > using the option that is supposed to handle that properly in my
73 > > stable software?
74 >
75 > The problem lies in a different place than the software itself.
76 >
77 Spoken like a true QA person. Glad this is the type of person we have
78 on our QA team.
80 This is why everyone makes fun of our QA team, because we allow people
81 in who don't actually give a shit about QA, only about covering up
82 issues so they appear good but don't actually fix shit.


Subject Author
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Tom Wijsman <TomWij@g.o>