| 1 |
El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió: |
| 2 |
> On Sun, 08 Feb 2015 11:17:19 +0100 |
| 3 |
> Pacho Ramos <pacho@g.o> wrote: |
| 4 |
> |
| 5 |
> > Many times has raised the question about how we could handle those |
| 6 |
> > packages (like icon packs, wallpapers...) that are not arch dependent |
| 7 |
> > and, then, could be stabilized all at the same time by the first arch |
| 8 |
> > team that is going to stabilize it. |
| 9 |
> |
| 10 |
> If you do that, then what is the point of having a stable request in |
| 11 |
> the first place? The many-eyeballs argument is gone then, so what are we |
| 12 |
> left with? |
| 13 |
|
| 14 |
The point is to test if it breaks depending on the arch, not to get it |
| 15 |
tested by maintainers + a random of arch teams depending on each package |
| 16 |
|
| 17 |
For example, for ubuntu-wallpapers package there is no need to overload |
| 18 |
three different arch-teams (or even more if it was keyworded on more |
| 19 |
arches) |
| 20 |
|
| 21 |
> |
| 22 |
> It isn't a team that is doing the stabilisation, it's a single person |
| 23 |
> who may or may not have looked at what the new version does and how |
| 24 |
> well it installs, and may or may not feel some pressure to rush it. |
| 25 |
> |
| 26 |
> As I said before many times, having more people on more architecture |
| 27 |
> teams look at the same problem actually helps catch bug at a late |
| 28 |
> stage but arguably still in time. Removing or weakening that last line |
| 29 |
> of defence (either by having a single person do stabilisations for |
| 30 |
> multiple architectures, or by removing most architecture teams from each |
| 31 |
> single task) will increase the bug rate for stable ebuilds (even more). |
| 32 |
> |
| 33 |
> |
| 34 |
> jer |
| 35 |
> |
| 36 |
|
| 37 |
Current situation only leads to stabilizations hanging for months with |
| 38 |
some arch teams having really big pending lists (taking care of their |
| 39 |
rate of stabling). Of course, if you want to have an exception for HPPA |
| 40 |
(as it has for other stuff like the profiles), there is no problem. We |
| 41 |
can keep leaving hppa there if you want to double check them (HPPA is |
| 42 |
not a problem as it has a stable tree that is small enough to be |
| 43 |
maintainable) |
Archives