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

[M. J. Everitt]

On 03/11/16 22:18, Rich Freeman wrote:
> 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.
>
With respect, the discussion here has comprehensively derailed from
-project issues. Discussion of the -stable and/or stabilisation should
really be diverted to the -wg-stable group and not clutter this channel.
Any queries as to the best method for this, I suggest pinging K_F (but
not naked!) who is project lead.

TYVM.