Pacho Ramos <[email protected]> napisał:
>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) But what if the wallpapers contain exploits that work only on specific 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) Of course there's always the option of dropping stable keywords. -- Michał Górny
