Re: [gentoo-project] Re: Call for agenda items - Council meeting 2016-11-13

[Rich Freeman]

On Thu, Nov 3, 2016 at 5:17 PM, William L. Thomson Jr.
<wlt-ml@××××××.com> wrote:
> On Thursday, November 3, 2016 1:14:20 PM EDT Rich Freeman wrote:
>>
>> ATs aren't developers, so they can't do commits.  The commits were
>> done by developers who were part of the arch project.
>
> I think that is going a bit far. I would say an arch tester can be a developer
> or contributor, with regard to the tester. When the tester is a developer,
> member of said arch team, they after testing mark it stable for given arch,
> and update bug.

Just to clarify, I was trying to indicate how the term "AT" was used
in the past.  I wasn't suggesting that we should have some kind of
two-stage workflow.

In the past developers certainly tested and stabilized packages
directly.  However, when they did this they were never referred to as
"ATs," but simply as developers.  I certainly support allowing
developers to continue to do this.

The purpose of ATs was to be able to allow contributors to be able to
do the heavy lifting (the testing, etc) and then just have a developer
do the commit.  The latter is really just overhead because we don't
have an easy way to make it possible for a contributor to directly
stabilize things without giving them access to do a lot of other
stuff.  If we could have a really light qualification process to allow
volunteers to test and stabilize packages without any developer
involvement I'd be all for it, as this is fairly low risk.

If I wanted to outline an ideal stable workflow managed by some kind
of tracker it would work like this:
1.  Packages get identified for potential stabilization.  This could
be based on time-based policies, user submissions, etc.
2. CI screens all stable requests and files bugs for repoman issues
and so on, before a human looks at them.  It could also do a build
test.
3.  Maintainers get the ability to screen these stable requests.  This
could be via an approval process with a deadline, or by being able to
set per-package policy (please stabilize one package in this version
range every three months), etc.
4.  Packages that pass the screen go into queues for each arch.  The
queue is dependency aware and marks things as blockers/etc as needed
to try to maximize the impact of each stabilization.  The system
blocks stabilizing things out of order/etc.
5.  An arch tester (a trained volunteer, but with focused training on
the task) evaluates the package, and can file a bug directly from the
tool, or mark it stable.  No need to look for repoman issues because
that was done in #2.  The focus is on whether it builds and runs
correctly.  Ideally there would be some kind of command line tool to
facilitate emerging the package.
6.  If it passes the tool commits the change.  This could be batched
to reduce git push volume.

-- 
Rich