On Fri, 2014-01-24 at 18:26 +0100, Tom Wijsman wrote: > On Thu, 23 Jan 2014 21:52:47 -0600 > Steev Klimaszewski <st...@gentoo.org> wrote: > > > The idea moves the work around, it doesn't lessen the workload at all. > > It is an idea to solve your actual problem, which isn't workload. > > You can easily find 7 people who have an armv7, and even v6, since the > > rpi is quite popular. > > They are easier to find than someone that has everything. >
The problem isn't finding someone that has everything - we have people that test on ARMv5, some that test on ARMv6, we have some that test on ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. So again, it just shuffles around the work, and does nothing to address the actual problem which is manpower with people that have the slower machines to finish their testing. Unless you would like to suggest that we maybe just say fuck anyone using a slow machine? I disagree, and think we should take care of all of our users, not just the bleeding edge and fast users. > > Getting them into the arch team and willing to run stable and > > actually test programs is a whole other story, which lead to you > > saying: > > > > "People that have certain architectures can just add themselves, no > > extra work again." > > Which is for people already on the arm arch; consider the context you > quote this from, rather than assuming what is not explicitly stated. > That doesn't make any sense - if they are already on the arm arch team, they are already in the list. That wasn't the context of the quote AT ALL. And I told you when you said that it would allow people to add or remove themselves willy nilly, and that is NOT going to happen - and would NOT be good for QA. > > What you've thrown out as a possible solution is akin to taking a pile > > of peas on the plate and moving them around the plate so that the pile > > doesn't look so big. > > In other words, using separation to organize them properly. > > > It doesn't change the amount of work, but you do need to look in more > > places for the work. > > Which you can collect back into one place. > > > Finding people with the hardware is the main issue, and I think I > > mentioned before, some people are simply unwilling to invest in > > "slow" hardware, so we have to rely on the people who DO have it. > > And if that means things take longer to stable, well, why is that an > > issue? Stable is supposed to be that - stable. > > That is because you only look for people that have all the hardware. > No, we do not look ONLY for people that have all the hardware. But until it's tested on all of the arm arches, it doesn't get stabled. So your suggestion is "split it out to blah blah blah blah" - so that moves it around - but you know what? the slower machines are STILL going to take forever (because they are slow!) and the ebuilds will still need to stick around, because we will still be waiting. Problem NOT solved, problem just moved around a tiny bit. > > So, as QA, shouldn't you be doing something about that, rather than > > pointing to some URLs on the web, telling me I'm in the wrong for > > using the option that is supposed to handle that properly in my > > stable software? > > The problem lies in a different place than the software itself. > Spoken like a true QA person. Glad this is the type of person we have on our QA team. This is why everyone makes fun of our QA team, because we allow people in who don't actually give a shit about QA, only about covering up issues so they appear good but don't actually fix shit.
