Gentoo Archives: gentoo-project

From: Daniel Campbell <zlg@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] Making "stabilization" a prerequisite to become a Gentoo Developer
Date: Thu, 05 Oct 2017 21:17:45
Message-Id: 20171005211730.GA1094@clocktown
In Reply to: [gentoo-project] [RFC] Making "stabilization" a prerequisite to become a Gentoo Developer by "Christopher Díaz"
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.
> > > 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 > > > > Christopher Díaz Riveros ChrisADR >


File name MIME type
signature.asc application/pgp-signature