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

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7173 bytes --]

On Fri, 24 Jan 2014 12:10:30 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:

> 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?

Consider how packages would rarely get stabilized if we had to wait for
all arches to test them first before adding any stable keyword at all.

Organize first, then get more manpower; otherwise we say the F-word to
everyone with a faster machine. Joining arm with a slower configuration
and have everyone waiting on you is a working condition to avoid; so,
we could have the slower configuration stabilize at its own pace.

Would we say F-word to 'em? No, we give them better working conditions.

> I disagree, and think we should take care of all of our users, not
> just the bleeding edge and fast users.

Theoretically, yes, everyone wants that; in practice, manpower as well
as performance is limited, which makes "taking care of all" a rather
hard to aim goal.

We still aim to satisfy everyone; I look at discussions from multiple
sides to see how we can satisfy as much people as possible, hence
providing multiple solutions. It however is rare that a solution works
for everyone, there are too much requirements for that to be possible.

But, making it hold up other people's work is a recipe for problems, to
which point someone comes up with a forced stabilization as you gave as
an example. In other words, minor configurations shouldn't stall things
forever; just like minor arches shouldn't stall things forever, which
would have been a huge problem if we would only allow stable keywords
to be added when all the arch teams have tested it.

> > > 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.

Being on the arm arch team alias, they can add themselves to the
individual configuration teams aliases; as per the context.

> That wasn't the context of the quote AT ALL.

It was:

@TomWij | Why would it result in more emails? When you are part of
multiple aliases you can have it filter down to one; or otherwise, you
can just sort them down to folders and only keep the revelant ones.
@steev  | so we should have armvX aliases?
@steev  | what if you want package X to be stable on only armv5 and
armv7 
@TomWij | Yes, then you just CC those.
@steev  | and those go to the arm alias, or we have to create armvX
aliases, and add people to that - again, more work for me, less work
for you - nothx
@TomWij | steev: People that have certain architectures can just add
themselves, no extra work again.

> 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.

You keep bringing up this assumption; it has been made clear multiple
times that so far, like for instance right after you have made it:

@steev  | no.
@steev  | the point of the arch team isn't so people can randomly pop
in, add themselves, do something, then leave the team willy nilly
@TomWij | Indeed, as I said half an hour ago.

Note that this comes right after the previous quote of the context.

And that reference to half an hour ago points to this:

@steev  | TomWij: because people are breaking stable, and if
someone isn't happy with the arch team's speed, they should join the
arch team to help out, and realize just how much work it ACTUALLY is
@steev  | should we allow anyone with an android phone to stable for
arm because they can throw a gentoo chroot onto their phone?
@TomWij | Under the condition proper arch testing is done, thus
according to arm's arch policies; that should be fine to do yes. If you
need it tested on multiple configurations, then I guess the person
could use multiple phones.

> > > 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.  

Your configurations problem would be solved, which is a good start;
so, let us fix actually fix it, instead of covering it up and waiting.

> > > 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.

Can we talk about the matter instead of about the person?

So, how to fix a problem in software when it is not in the software?

PS: Note that I have been devaway for almost two weeks.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]