| 1 |
On Thu, Nov 3, 2016 at 12:41 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> Yep pretty much. The different in my suggestion would be that |
| 4 |
> stabilization commits would be done by those that don't actually test |
| 5 |
> said arch -- I think the way it worked before is that the |
| 6 |
> stabilization commit was still done by an AT. |
| 7 |
|
| 8 |
ATs aren't developers, so they can't do commits. The commits were |
| 9 |
done by developers who were part of the arch project. |
| 10 |
|
| 11 |
Unless you're using "AT" to refer to either a non-dev arch tester or a |
| 12 |
developer member of the arch project team. It is possible that the |
| 13 |
term wasn't used consistently, but on amd64 back when it was active I |
| 14 |
don't think we used the term AT for anything other than non-devs. |
| 15 |
|
| 16 |
> This lack of on-system |
| 17 |
> verification from the committing dev would be why we'd need a higher |
| 18 |
> level of trust from the non-dev ATs. |
| 19 |
|
| 20 |
Generally speaking the arch project member wasn't checking anything |
| 21 |
other than that the AT was in fact an AT for their arch. So, it |
| 22 |
required the same level of trust. |
| 23 |
|
| 24 |
However, you're right that the commits could be done by anybody, or as |
| 25 |
I suggested they might even be automated. Arch testing really seems |
| 26 |
to be the sort of thing that could go into some kind of tool that |
| 27 |
tracks all the statuses/etc and as testers check in it just does the |
| 28 |
commit behind the scenes. |
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives