Re: [gentoo-project] [RFC] Making "stabilization" a prerequisite to become a Gentoo Developer

[Rich Freeman]

On Thu, Oct 5, 2017 at 2:17 PM, Daniel Campbell <zlg@g.o> wrote:
>
> I think your idea is noble, but it comes down to "do QA and Arch testers
> care enough to make their job easier and invite others?" I suspect there
> are territorial behaviors at work that prevent people from learning and
> improving their packages through testing. As long as our culture is
> insular, this problem will remain.
>

I don't really think this is the problem.  If somebody wants to chime
in and say that they have been dying to arch test but some arch team
is keeping them away please do so, but my sense is that there just
isn't a lot of interest in it.

Face it, arch testing is tedious.  There isn't any mystery as to how
it works.  You install a package, use it a bit, and generally make
sure it works.  Then you commit a keyword change.

Now, perhaps the whole process could be radically transformed, such as
using automated testing, just compile testing, and improved reporting
tools/etc.  The issue there is that this is a completely different set
of skills than what current arch testers are actually doing.  It is
also one of those areas that a few people talk about but few put much
time into.  Most of the people who do talk about it aren't arch
testers (nor do I imply that they should be, or that arch testers
should be doing this work - I'm just pointing out that blaming arch
testers misses the mark).

The QA team really has nothing to do with the arch testing process.

Now, maybe there are some barriers, such as arch teams that don't
really allow non-dev arch testing.  Back in the original amd64 arch
test days where the concept was pioneered the typical process was:

1.  Non-dev trains as arch tester.
2.  Non-dev takes a test to be certified as an arch tester.  This was
administered by the arch team - no recruiters/etc involved.  The arch
tester status was just an arch team thing - it didn't have any formal
Gentoo-level recognition really.
3.  Arch tester reviews stabilization/testing bugs and marks those
they have tested.
4.  Arch team members monitor bugs tagged as having been tested.  They
immediately commit changes without further testing.

For this to work you really need #4 - if arch testers just submit bugs
for them to end up in a backlog while a dev re-tests them then there
is little benefit to the process.  Back in the original amd64 AT days
it was rare for more than a few hours to pass between an AT marking a
bug as tested, and the commit being made.  I'm not sure why it wasn't
automated - probably just laziness.

In any case, for any of this to work people need to WANT to arch test.
I doubt that trying to force people to arch test will help.

-- 
Rich