On Fri, Nov 11, 2011 at 4:32 AM, Brian Harring <ferri...@gmail.com> wrote: > On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote: > One thing that is less obvious is that there are essentially two > flavors of unstable chromium- dev and beta. Currently beta is 17.*, > dev is 16.*. If you don't want bleeding edge, but want faster than > stable, pmask 17.*.
I agree that the solution to this particular problem is to run stable. However, it is worth noting that chromium deviates from the normal gentoo testing workflow quite a bit. For a typical package new builds are introduced as a higher version, stay in the tree for a month, and then get marked stable. Often not every version makes it to stable, so there is little churn in the stable version. For chromium new builds are introduced as a higher version for the unstable branches, but never make it to stable. Instead, typically stable gets updated as a result of security/bugfixes with new versions being introduced into the tree and quickly being stabilized. Since the new versions are lower than the existing unstable versions nobody but the developers ever actually test them. So, the stable branch of chromium doesn't benefit from extended testing by the ~arch community. The only way it could get tested is if a particular build was released from dev to beta without any changes, and then from beta to stable without any changes - which never happens. Now, this is mitigated to an extent by the fact that Google is following a relatively strict upstream QA process. A similar situation exists with the kernel where new stable LTS versions get introduced and yet never hit the ~arch users who are using versions beyond them. I'm not sure the current situation is "broken" per se and needs fixing. But, the interaction of upstream QA and Gentoo QA is something that we might want to think about. Since most upstream projects have nowhere near the level of QA as either chromium or the kernel this isn't going to be a widespread issue. Rich
