| 1 |
On 03/11/16 10:01 AM, Rich Freeman wrote: |
| 2 |
> On Thu, Nov 3, 2016 at 9:50 AM, Ian Stakenvicius <axs@g.o> |
| 3 |
> wrote: |
| 4 |
>> |
| 5 |
>> The stabilization commit itself isn't that onerous, it's the |
| 6 |
>> testing. Likely a keyword or whiteboard from the non-dev AT on |
| 7 |
>> the stabilization bug would suffice no? |
| 8 |
>> |
| 9 |
>> That said, like the proxy-maint group, we could enlist some |
| 10 |
>> random devs to apply the stabilization commits based on the |
| 11 |
>> feedback of non-dev ATs. BUT, that's only going to work if we |
| 12 |
>> have some sort of enforced training and qualification criteria |
| 13 |
>> for non-dev ATs (which we likely have already) and I'm not sure |
| 14 |
>> the bureaucracy to manage that would leave us in a better |
| 15 |
>> situation than what we have now. |
| 16 |
>> |
| 17 |
> |
| 18 |
> You're basically describing how ATs worked back when they were |
| 19 |
> active. |
| 20 |
> |
| 21 |
> An AT would search for packages keyworded for testing/stable on |
| 22 |
> their arch. They would perform testing, and comment on the |
| 23 |
> results. If it passed they'd add a keyword. |
| 24 |
> |
| 25 |
> Devs on the arch team would search for packages keyworded by ATs |
| 26 |
> on their arch. For the most part they'd just blindly commit |
| 27 |
> anything that was marked, because only trained ATs would be adding |
| 28 |
> the keywords. |
| 29 |
> |
| 30 |
|
| 31 |
Yep pretty much. The different in my suggestion would be that |
| 32 |
stabilization commits would be done by those that don't actually test |
| 33 |
said arch -- I think the way it worked before is that the |
| 34 |
stabilization commit was still done by an AT. This lack of on-system |
| 35 |
verification from the committing dev would be why we'd need a higher |
| 36 |
level of trust from the non-dev ATs. |
| 37 |
|
| 38 |
Of course if the current bottleneck isn't that of the AT dev(s) for a |
| 39 |
given arch, then this wouldn't improve anything anyhow. |
Archives