Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Steev Klimaszewski <steev@gentoo.org>]

On Fri, 2014-01-24 at 18:26 +0100, Tom Wijsman wrote:
> On Thu, 23 Jan 2014 21:52:47 -0600
> Steev Klimaszewski <steev@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.