Re: [gentoo-dev] [RFC] QA Team's role

[Grant Goodyear]

Stephen P. Becker wrote:
> Grant Goodyear wrote:
>> Ciaran McCreesh wrote:
>>> My point is that that's a nasty QA bug that's relying upon input from
>>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>> around filing more similar "breaks non-interactively" bugs because the
>>> discussion will just get repeated over and over.
>> Huh?  I just read through the bug, and it actually appears to be
>> resolved pending Chris' testing w/ the needed USE flags added to the
>> various profiles.  I'll admit that the fix is inelegant, but I'm missing
>> where it's waiting upon Stuart for additional info.  Am I missing something?
>
> Yes, you are missing that the bug really isn't fixed.  There are still
> USE combinations which would be otherwise perfectly valid, but which
> cause php to fail to emerge, thus reaking non-interactivity and forcing
> people to (ab)use /etc/portage/package.use to get things working properly.

Well, I did say that it was an inelegant fix....  In any event, I
appreciate your response about php brokenness (I'll come back to this
below), but does this php brokenness require additional info from Stuart
to fix?

Let me try breaking things down a bit to see if I can understand the
various specific problems:

0.  Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other
very much.  *Shrug*  That's not really a problem, it just means that one
needs hip-waders to get through all of the muck.  No big deal; that's
part of being a dev with a really large project.

1.  A fresh Gentoo install w/ default USE flags will fail to compile
dev-lang/php.  That one is being "solved" by adding some additional USE
flags to the default profile.  The claim from the php team is that the
correct fix is a version of portage with USE-based dependencies.  The QA
folks would prefer to see the php ebuild implement a set of sane
defaults to prevent breakages, instead, if I understand correctly, which
in practice would mean that the ebuild would detect whether or not deps
were built with the correct USE flags, and work around any "broken" deps
 in the ebuild.  (I must be missing something, since the latter strikes
me as notably _bad_, since it would mean that two people with identical
USE flags would get different outcomes depending on how their
dependencies are built.)

2.  There are a variety of otherwise-valid USE-flag combinations that
will cause php to fail to build (or be otherwise unusable).  That's
hardly surprising, since dev-lang/php has ~100 USE flags, which means
~2**100 (~10**30) possible USE-flag combinations.  Let's see, there are
roughly pi*10**7 seconds per year, so if we could test one build of php
per second it would only take considerably longer than the lifetime of
the universe to test all of the possible combinations.  Clearly QA of
the current ebuild has to be rather illusory.  Do we have a bug open
about this?  Are there any reasonable suggestions on how to fix it?  I
do realize that the problem is complicated by the fact that people
really do use fairly esoteric php builds on production machines.  That
said, the current situation really is a nightmare!

3.  There are a number of people (not just ciaranm) who consider the
webapp idea to be brilliant in concept, but horribly flawed in its
execution.  (I'm personally fairly agnostic, although the one time that
I had to create a webapp-enabled ebuild I found the process to be
incredibly confusing.  I just assumed that with great flexibility comes
great pain.)  However, I've never known precisely why people feel that
way, and I can't find any bugs about it, so perhaps we could have a real
debate about this issue?  I don't think that bug #120088 is it.

-g2boojum-