| 1 |
On Tue, Jul 25, 2017 at 10:13 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> I feel like this is going towards 'anybody can do keywording / |
| 4 |
> stabilization'. I'd rather not go this route right now, and just let |
| 5 |
> arch teams recruit people as they see fit. |
| 6 |
> |
| 7 |
|
| 8 |
I think this depends on the arch team. |
| 9 |
|
| 10 |
Back in the early days of amd64 I was an AT and an early adopter in |
| 11 |
general. There were a lot of bugs with types/etc and broken |
| 12 |
assumptions. It was helpful to have a team that was familiar with the |
| 13 |
most common problems and which had the hardware to test things. |
| 14 |
|
| 15 |
Now we never see an amd64-specific issue because that is what all the |
| 16 |
upstream projects do their own QA using. If anything we'd be more |
| 17 |
likely to see x86 bugs, but most people have learned how to use types |
| 18 |
correctly/etc, and I suspect this has benefited other architectures as |
| 19 |
well. |
| 20 |
|
| 21 |
I saw an analogous situation with systemd. In the early days we were |
| 22 |
writing a lot of units. These days it is just dealing with one-offs |
| 23 |
as much of the work is now upstreamed. |
| 24 |
|
| 25 |
I think that the more mainstream something is, the less the need for |
| 26 |
specialized teams to deal with every issue. Sure, somebody could |
| 27 |
always escalate a sticky problem, but having an arch team do every |
| 28 |
stabilization seems like having the gcc team look at every build |
| 29 |
error. |
| 30 |
|
| 31 |
-- |
| 32 |
Rich |
Archives