| 1 |
On Thursday, November 3, 2016 1:14:20 PM EDT Rich Freeman wrote: |
| 2 |
> On Thu, Nov 3, 2016 at 12:41 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 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 |
I think that is going a bit far. I would say an arch tester can be a developer |
| 12 |
or contributor, with regard to the tester. When the tester is a developer, |
| 13 |
member of said arch team, they after testing mark it stable for given arch, |
| 14 |
and update bug. |
| 15 |
|
| 16 |
That does not mean devs just go and mark their own stuff stable. Usually the |
| 17 |
proper way to do even that, is to be a member of what ever arch team. If said |
| 18 |
dev wants all archs, have to join all arch teams. After 30 days, etc. |
| 19 |
|
| 20 |
It is not really efficient to have contributors be testers. Just to have another |
| 21 |
do the commit, and vouch for said testing. Some testing is quite minimal, |
| 22 |
which may be better automated than manual, given recurring nature. |
| 23 |
|
| 24 |
Also in part goal should be less contributors more developers, so no need to |
| 25 |
differentiate an arch tester who cannot commit, to a developer doing arch |
| 26 |
testing and stable commit. |
| 27 |
|
| 28 |
AT can be confusing as an acronym, not really clear if it means Arch Tester or |
| 29 |
Arch Team. |
| 30 |
|
| 31 |
-- |
| 32 |
William L. Thomson Jr. |
Archives