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