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

[Daniel Campbell]

On Sun, Oct 01, 2017 at 06:13:32PM -0500, Christopher Díaz wrote:
> Hello everyone,
>
> I would like to propose to the community a new policy in the process of
> "becoming a developer". Here is the initial draft, do not hesitate to
> point out anything that needs to be discussed.
>
> Abstract
>
> Given the necessity of testing and stabilizing software in Gentoo Linux
> and the ammount of testers is not enough to test all the packages on
> the given architectures, this GLEP proposes to make the "testing" and
> "stabilization"  processes a required stage to become a Gentoo Linux
> Developer.

Firstly, thanks for taking the time to draft something. It's evident you
care about testing quite a bit. :)

I don't think requiring every developer to test packages to Arch team
standards will do the distro much good. Building a distro has a
multitude of facets, and developer skillsets will not be uniform across
the distro. We all come from different backgrounds, education,
interests, and specialties. I'll explain more below.

>
>
> Motivation
>
> The necessity of manpower in Gentoo Linux is obvious and several
> projects need more people to be able to achieve their goals. One
> critical project is the Arch testers project, which needs people to be
> able to know the procedure to test and mark as stable a given package,
> this impacts on the whole community because if arch testers are not
> capable to test all the needed packages, all the other projects can't
> go further with their goals.
>
> At this point, the process to become a Gentoo Developer does not
> explicitly require testing and stabilization. As this part is crucial
> to better understand how to fix ebuilds, each future developer should
> know the procedure to test and stabilize not only their own packages,
> but to help other developers in the stabilization work.
>
> The AT Project was created on January 2005 to reduce the developer's
> load and the amount of open keywording bugs for the amd64 porting team.
> Since then many users have volunteered to become ATs and after that
> became full developers. GLEP 41 already tried to give arch testers a
> "staff" status in the community, but rather than creating a new status,
> this new "stage" in the "becoming developer" procedure should be
> considered as a test of perseverance. At the same time, this is a great
> way to teach gentoo users how portage works and how to debug their
> future ebuilds.
>
> Prepare the next generation of developers to be able to test and
> stabilize their own packages, and help other devs in stabilization,
> would benefit the whole community and give all mentors, recruiters and
> users wanting to become a official gentoo developer a starting point
> with endless work to do, and at the same time mentors and recruiters
> would have a place to look for prospectives developers.

While well-intentioned, we need to consider the work that will go into
training said developers -- new or old -- to adapt their workflow to fit
in testing. If we simply make package testing another hurdle in the
journey to become a developer, what we end up with is a lot of packages
*claimed* to be tested, but since the people doing all this new testing
aren't as skilled at it, there will be packages that slip through the
cracks, and those people will be chastized by senior members. I've seen
it happen personally, and can dig through archives if anyone wants to
challenge that statement.

If we want more developers to be better package testers, we need better
documentation, better tooling, and a more forgiving culture. The same
goes for QA, which as far as I know oversees the technical integrity of
the tree and thus would have a hand in the testing cookie jar.

>
>
> Specification
>
> In order to stablish this new policy, we need to complete this list of
> tasks (minimun required in my opinion):
>
> -As test and stabilization is arch-based, we need all AT teams to try
> to prepare an "official" procedure (all of them have very good
> guidelines right now).

These guidelines need to be more visible. Documentation is useless if
it's not disseminated so people know about it.

>
> -Mentors and recruiters should encourage recruits to test as much as
> they can, on all the given arch they are interested to, or have access
> to.

I'm fairly sure we already encourage new recruits to consider testing
packages. A "Starter's Guide to Testing/QA" would be a good fit for
that, assuming those teams want to get more people on-board.

>
> -The official ebuild-quiz already has an specific "arch testing"
> question, maybe as a Proof of Concept, the recruit should add bugs
> where he/she could proof that he knows the testing procedure.

I see this as creating bugs for little gain. The minutiae of bug
configuration is a subject of endless nitpicking. Bug filing standards
should be explicit and unambiguous. The problem with arch testing, like
just about every other part of Gentoo, is the poor rate of knowledge
transfer. A lot of details are kept in the heads of people rather than
being laid out in the open. While there is documentation for some
things, as I said above it's not very discoverable and our culture is
unforgiving. It's no surprise that people aren't chomping at the bit to
test packages; if things aren't 100% perfect, you get yelled at. Nobody
wants to volunteer on a project that will yell at them.

>
> -As many users starting in gentoo will start by testing and
> stabilization, AT teams would need to remember that they would interact
> with maybe not so experienced users and try to make the procedure as
> clear as posible to follow.

+1

>
>
> Rationale
>
> This solution aims to solve a more long-term problem, which is the
> necessity of having developers prepared to start a stabilization
> process if needed and not depending on an arch tester. The reality is
> that most current Gentoo Developers and Projects are overwhelmed with
> the ammount of work, but if all developers could help by testing
> another's package, maybe this could reduce the work or at least the
> time spent waiting for stabilization.

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.

This looks like a situation that QA and Arch testers should issue public
statements on. They work closest with package testing and it's a good
opportunity for them to let the rest of the community know how things
are going. I can't speak for others, but I'd like to read what they have
to say on the matter.

Thanks again for sharing. Hopefully this initiative will start
constructive discourse.
>
>
> Copyright
>
> This work is lecensed under the Creative Commons Attribution-ShareAlike
> 3.0 Unported License. To view a copy of this license, visit https://cre
> ativecommons.org/licences/by-sa/3.0
>
>
> Christopher Díaz Riveros ChrisADR
>